Installing advanced-systemui (0.2.6) has been a disaster for me.
Upon installing, it didn't stopped osso-systemui, I had to stop it by hand (having had a look at the postinst script, I see it doesn't run "/etc/init.d/osso-systemui stop")
I tryed changing the governor to conservative, since then, advanced-systemui kept crashing with a lot of cpu usage from dbus each time I tryed to bring it on. Restarting it didn't helped
Once uninstalled, the tablet doesn't fully boot anymore. The progress bar goes to the end and stays there, it doesn't reach the shaking hands logo. I'm trying to figure what's wrong but still I couldn't. What does your program modify in the system to be able to cause this effect?

The init.d script stops and starts osso-systemui when ASUI is started or stopped.

It doesn't modify anything, other than stopping osso-systemui. A corrupted ASUI install could probably cause a startup hang and infinite reboot loop when it detects problems trying to start ASUI. Maybe the application manager didn't properly uninstall the package and the system is still trying to run it at boot.

You could try using the flasher to put the device in R&D mode, get it to boot and then make sure the /etc/init.d/advanced-systemui file doesn't exist.

I have a dual boot setup, so I was able to boot into the alternate system to do the recovery.
Yes, I checked there were no stale rc.d links, uninstallation was correct in that respect. Also, I checked there were no disk corruptions (system is in ext3).
Finally, after much going back and forward trying to find where the problem was, I managed to get it to boot again today. Unfortunately, I'm not sure where the failure is, because it booted ok just after I managed to enable syslog and rc.d logging.
The last thing related to advanced-systemui I touched before it booted again correctly was the gconf dsm settings, so I think it could be that.
Today I'll do a backup of the main system and I'll try again. Let's see what happens.

By "gconf dsm settings" do you mean the system keys in /system/osso/dsm/? How did you "touch" them?

Yes, exactly those. I found it had been modified at the time of advanced-systemui with gnu's find (busybox's find is almost useless). I copied the key's xml for /system/osso/dsm/locks file from the recovery system.
I'm going to install advanced-systemui again right now, I'll report back (let's hope everything happens again the same)

YEP!!!! Exactly the same! But now I have:rc.d and syslog loggin, modification timestamps of all files before installation, and a full backup
Now we can do some decent forensic analysis

What happened till now:
Installed advanced-systemui 0.2.6 with "dpkg -i": installation went correctly (like the first time), but again osso-systemui wasn't stopped. advanced-systemui init script tryes to stop osso-systemui with invoke-rc.d and that's what fails.
Stopped osso-systemui by hand
Changed governor to conservative mode: advanced-systemui crashed and kept crashing when pressing the button.
Uninstalled advanced-systemui with "dpkg -r": uninstallation went correctly, advanced-systemui was stopped, but osso-systemui wasn't started.
Started osso-systemui by hand
Rebooted: now the system hangs at boot with the same symptoms. Still can use the button to turn it off.

Now I'm going to reboot into the recovery system and do further analysis.

Finally, the hang at boot is completely unrelated to advanced-systemui.
It just happened that I have added the keychain shell script to my system, and in order to run it every time a xterm is opened, I added a perfectly valid line in /home/user/.profile.
Guess what? Modifying ~/.profile or ~/.bashrc can cause maemo to hang at boot
The hang happened in /etc/init.d/af-services. This script runs /etc/osso-af-init/real-af-services using "su - user", so the ~/.profile is executed during the boot process.
Yet another wonderful Nokia design decision
So, the remaining issues are: not stopping osso-systemui at install/boot (invoke-rc.d is unreliable), not starting osso-systemui at uninstall (prerm script lacks the line to start it), crashing after changing the governor, cpu usage (governor always says it is running at 400 Mhz when the advanced-systemui window is opened). I'll use the debug binary to see why it crashes.

I ran my power mode to conservative, and now asui crashes the instant it opens.
I see a flash but then iit's gone.
And whats this escape key?? keyboard or screen? hardware?
I also have telescope on, and I pressed home and went to the home screen and it still came up top, not sure if that has any effect or not.
N810

ran a gdb on the test binary, and it seemed to die with a libc error.

seems btw, that null have much the same effect as conservative.

To recover one can do this (as root in a terminal): echo ondemand > /sys/devices/system/cpu/cpu0/scaling_governor

as it will reset the governor to ondemand

This happens after any notification, when the ASUI window is displayed. I don't know which system service is providing that notification; "offline mode activated" is one example, but yukop4 mentioned the "shadow" left behind when wi-fi is turned on. Also for the lock / unlock notifications ("Screen and keys locked")
It's just a little grey area filling the round-cornered rectangle where that message was.

On my N800, I just tried this with no windows besides the search and clock applets. A second after rotation, the (new) top half goes black with "rotating... rotating..." across the middle of the screen; then a few of the widgets come in, then a long pause, then a few more widgets, then no further updates until the screen redraws. But closing ASUI entirely, then restarting, it instantaneously fills the screen as expected.

I still think simply closing the UI entirely on rotation is quick, simple, and intuitive. Similarly, if you can manage the "go dark now" feature, I would not want the ASUI display to be there after I tap the screen to wake it up.

Yes, it shows "Connecting..." and "Connected" (in red). In response to a question you asked wklink: The connection is from my saved list - in fact, I've seen this on two saved connections this week. I had a connection to a non-saved airport network earlier this week but didn't look to see how that displayed.

I agree, this isn't a trivial problem and I don't have a good suggestion. I'm OK with how it is, that idea was just brainstorming.

I don't know which control panel option you're referring to. I haven't installed gconf yet, so I'm running with defaults. My current settings for dimness are 30 seconds to dim, 1 minute to black. When I click Lock (not on charger), it dims as soon as the "locked" notification is hidden, then goes black 30 sec later.

I agree that messing with those settings isn't good. Is there no API to force the system to go dark immediately?

I noticed a new feature, and related to this there's a bug. I had the N800 off, with low battery, after using it for playing music on a plane trip. I'd used ASUI to shut the unit off. When I got home, I plugged it in to charge it up, and saw it go into the standard "charging battery" display. I came back later and saw the screen was all-black but illuminated; I tapped it and ASUI was displayed. I left it alone and the screen went completely dark afterwards.

I like the automated power-up on charge, but I don't want that black-but-illuminated screen, and I don't want ASUI as the underlying display.

Great! Looking forward to this feature.

As noted by someone else, it requires changing the slider position and then changing it back, fiddling with it to get to the same level as before. When you mute your TV, do you turn the volume down to zero, or do you press the Mute button?