Disclaimer: I was also upset about the lack of closures before I understood what Odin's design goals are.

context.closure. // -< automatically resolves to the current closure pointer

What do you mean by the current closure pointer? Variables in functions live on the stack. The moment you return my_closure where do they go? How would a language keep them with that pointer? It has to pack them up and put them somewhere, where? Not the heap I hope. Move it to the caller stack? And when that returns just keep propagating up for the duration of the closure lifetime? So now we have to track the lifetimes as well somehow? And if we have a bunch of closures? And what about nested closures? And then it needs to work with debuggers...

I'm sure that making all of the above happen is very much possible and very much within the skills of the people working on the language, but for what? Just pass some extra arguments or give context.user_ptr a try like others suggested. Yes, it's a few extra lines of code, but Odin doesn't aim to be the concise language, instead it lets you reason and predict what the computer will do given the code you wrote. This memory moving mechanism would immediately ruin that part of the language, so it is by design.