[Samsung Captivate Glide] roothorick:
Triple-posting to avoid size limit.

I was able to reproduce #2 in UCLH2 without mods, but #1 now behaves differently, and doesn't result in a hang. The new behavior suggests a bug in GTasks was aggravating a problem in the ROM that's since been fixed. I'm basing this guess on two lines that jumped out at me in logcat:

E/ActivityThread( 1456): Failed to find provider info for org.dayup.gtask.key
...
W/PhoneWindow( 1456): Previously focused view reported id 2131099807 during save, but can't be found during restore.

About #2, I just noticed the process starts a lot earlier in the logcat. Here's the bits I unwittingly left out:

D/MainActivity( 2637): onPause()
D/MainActivity( 2637): onStop()
D/MainActivity( 2637): onDestroy()
D/libemu.so( 2637): (./jni/EmulatorBridge.cpp:76) destroy()
I/libemu.so( 2637): called closePcm when pcm already off
D/libemu.so( 2637): (./jni/Application.cpp:152) Start Application.destroy()
D/libemu.so( 2637): (./jni/Application.cpp:175) Finished Application.destroy()
I/InputReader( 186): Reconfiguring input devices. changes=0x00000004
I/InputReader( 186): Device reconfigured: id=5, name='sec_touchscreen', surface size is now 480x800, mode is 1
D/STATUSBAR-PhoneStatusBar( 431): onConfigurationChanged - Configuration:{0 1.0 310mcc640mnc en_US layoutdir=0 sw320dp w320dp h508dp nrml long port finger qwerty/v/h dpad/v s.25}
W/systemui/quicksettingpanel( 431): prepareTranslationXfalse 0
D/libemu.so( 2637): (./jni/Application.cpp:1490) saveState(10)
D/libemu.so( 2637): (./jni/Snes9xSystem.cpp:289) S9xChooseFilename result: /mnt/sdcard/external_sd/SNESDroid/states/.010
F/libc ( 2637): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1)
D/NvAppSpecificHeuristics( 431): found matched app. wanting to force double buffering
D/STATUSBAR-PhoneStatusBar( 431): updateExpandedSize:0
D/STATUSBAR-PhoneStatusBar( 431): updateExpandedSize:0
D/systemui/quicksetting/QuickSettingButton( 431): ACTION_CONFIGURATION_CHANGED - mBtnText.setText();
D/systemui/quicksetting/QuickSettingButton( 431): ACTION_CONFIGURATION_CHANGED - mBtnText.setText();
D/systemui/quicksetting/QuickSettingButton( 431): ACTION_CONFIGURATION_CHANGED - mBtnText.setText();
D/systemui/quicksetting/QuickSettingButton( 431): ACTION_CONFIGURATION_CHANGED - mBtnText.setText();
D/systemui/quicksetting/QuickSettingButton( 431): ACTION_CONFIGURATION_CHANGED - mBtnText.setText();
D/STATUSBAR-NetworkController( 431): onReceive() - ACTION_CONFIGURATION_CHANGED
D/STATUSBAR-Clock( 431): onReceive() - ACTION_CONFIGURATION_CHANGED
D/STATUSBAR-Clock( 431): updateClock :18:00
D/STATUSBAR-DateView( 431): updateClock :09/15/2012
I/DEBUG ( 103): *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***

At which point it launches into the big debugspam.

My theory: The SNESDroid NDK code segfaults, due to a legitimate bug in the app itself. The parachute that launches is something added to testing builds by Samsung, which is supposed to catch as much useful debugging info as possible and haul it off to some developer's DropBox account. Because the SNESDroid crash happens in NDK code, the segfault is broadcasted at the hardware level, triggering the aforementioned parachute, which was never made to handle an app crash, and causes some weirdness at the system level as a result.

So tl;dr it's just buggy apps. UCLG9 has its own bug that's triggered by one of them but that bug has been fixed in UCLH2. I'm going to apply the keyboard backlight fix and try again just to be sure. Installed root and keyboard fix, behavior has not changed.