Despite the article name suggesting it'd be highly TRB-specific, I ended up with a pretty generic summary about concurrency. It's because I didn't have a clear picture even of the concurrency basics in my head; discovering it while I was trying to finish a patch. I might continue on the topic some other day, in form of another article, or even a book-style chapter/specification. Time will tell...

Re your TRB documentation points: I think were well worth mentioning in this context, and I find the presented open questions entirely justified!

One of them would be a documentation of the memory/concurrency model, which is, I believe, what you're considering. Still, there are a few interesting unanswered questions here in my opinion: what dynamic data handling is TRB performing at run-time? which of is it assumed to be thread-local and what portion of it is considered to be "shared" between threads? what synchronization primitives are used for protection and how? Concurrency is a bitch, what with data races, lock ordering and indefinite postponement issues, so maybe there's a few ways to get TRB to hang merely through bad synchronization design. Maybe, I haven't really looked, to be honest.

The other would be a line-by-line annotation of the code with what it actually does, especially with respect to assumptions in the previous paragraph. It's a ton of work, but I for one see no other way to guard TRB against future exploits. The good part is that it only needs to be done once, and it's done for as long as Bitcoin remains a thing.