to back up a bit, what exactly would you want to be available in this scenario ?  i'm guessing things that are "passive" ... so crosh's shell command.  maybe we start there ?

we could add a flag file to the stateful partition that crossystem would check in addition to cros_debug ... if it exists, then it would lie and say cros_debug is disabled.

the write protect knob has a "boot" and "cur" distinction.  we could do the same here:
cros_debug == cros_debug_cur == what everyone tests == looks at existing data source, and additionally checks the stateful partition for a flag file
cros_debug_boot == new knob that only things like crosh would check

I tried to answer that here: :-)

"I think that what I want here is a way to exercise these code paths while still retaining the ability to SSH to the device. We'd presumably need to carve out the ability to continue running SSH in this mode."

I'm not sure that being able to run crosh would've helped in this case, since the hang only occurred when the ui job was stopping (making crosh unavailable).

SSH probably would've helped (I was able to repro the problem while remaining connected over SSH on a dev-mode machine where I'd forced this code to run).

frecon might've helped too, although I'm not sure whether I would've been able to switch to it while in this state.

so we want:
- sshd (+ ability to login)
- crosh
- frecon (+ ability to login)

those all pass the "passive" test so should be fine.