So I actually do think there is one problem with this: thread locals (equivalent to statics in the multithreaded scenario). We bound static variables by Sync, which lets us control what we put there with that trait, but thread locals have no such bound. Thus, if a poison bit is too expensive for RefCell in the normal, no-try case (and it probably is–it isn’t dwarfed by the cost of the lock like Mutex), there isn’t any real way of preventing exception safety issues in thread locals. Unfortunately I think the right way to do this (create parallel traits for single threaded exception safety, bound thread locals by them, and create an alternate RefCell [and likely Cell]) would have to have already happened by now, as doing this would break lots of existing code (unless the thread local stuff is not going to be stable for 1.0?).
I think that’s the only major problem. With OIBIT and without thread locals, we could easily prevent direct sharing of thread memory altogether by using Send + 'static (and we’ve already implicitly agreed that anything else that makes it through that bound is okay to mutate, which I would like better frankly since Cell and RefCell aren’t exactly like atomics and mutexes; in particular, you don’t usually assume that someone else might access them the moment after you release the “lock”).
