Ah I missed that thread, thanks. It's based on an earlier version of the proposal Niko and I put up on the async fundamentals repo.
The answer might be similar to how I was planning to deal with dyn, which is to qualify each dyn with a with clause. I don't see why we couldn't do the same for function pointers. But this naturally leads to the question of whether we need the ability to qualify all types like this. (EDIT: On second thought I don't think that's true, we only need to qualify dyn and function pointers. You couldn't construct a struct that had an unqualified fn pointer with a qualified fn pointer.)
Actually calling it would look similar to the solution for dyn, which could be to collapse all context into a single parameter that allows name-based lookup, or use a compiler-managed thread local. We can also use the approach used to implement #[track_caller] here to have reified functions with different ABIs depending on whether the caller is expecting to pass the specific context a function is expecting or just a "generic" context map.