Regarding the implementation of Odin's `context` not being thread-local, source from here: https://www.gingerbill.org/article/2025/12/15/odins-most-mis...

Another common question I’ve gotten a few times is why the `context` is passed as an implicit pointer argument to a procedure, and not something like a thread local variable stack? The rationale being that there would not need to be a calling convention difference for `context`. Unfortunately through a lot of experimentation and thought, there are a few reasons why it is implemented the way it is:

* Easier to manage across LIB/DLL boundaries than trying to use a single thread-local stack

* Easier management of recovery from crashes where the context might be hard to figure out.

* Using the existing stack makes stack management easier already, you don’t need to have a separate allocator for that stack

* Some platforms do not thread-local variables (e.g. freestanding targets)

* Works better with async/fiber based things, which would then require a fiber-local stack instead of a thread-local one

* Prevent back-propagation, which would be trivial with a global/thread-local stack

Odin’s context also has copy-on-write semantics. This is done for two reasons: to keep things local, and prevent back-propagation of “bad” data from an third-party library (be it malicious or just buggy). So not having an easily accessible stack of context values makes it harder for this back-propagation to happen.

Yeah, all valid justifications.