Fixing this actually ended up being a lot simpler than I anticipated (and it requires no changes on our end). All that's really required is saving and restoring:
- tstate->cframe->current_frame
- tstate->datastack_chunk
- tstate->datastack_top
- tstate->datastack_limit

You can see my proposed fix for Greenlet here (this PR also contains some other 3.11-related fixes):

https://github.com/python-greenlet/greenlet/pull/280

There is one weird edge case in Greenlet's use that I don't *entirely* understand, where it sometimes needs to update a thread with a NULL frame (as discussed above). We need to replace the thread's datastack with *something* in this case: setting it to NULL crashes the interpreter when it tries to allocate frames later, but leaving it as-is puts us in a situation where two threads are sharing the same datastack (also a recipe for crashes). My solution is to set it to a statically allocated zero-size "dummy chunk" in this case. It seems to work fine, since the zero-size forces the interpreter to allocate a "real" chunk on the next frame push.

If this solution seems too hack-y, a very simple change on our end could be to start treating NULL as a valid datastack value, and have the thread state check for it when pushing new chunks. That would make for a relatively clean upgrade path for libraries like Greenlet, and doesn't require adding any new APIs.