Maybe I'll try to verbalize better why I think this proposal is useful (just to express my own point of view on the matter). I listed off a number of use cases already, some of which are more important than others, but I think the primary thing this proposal provides is the proper facilities to deal with "variadic dependencies" (I made that phrase up, but I'll explain what I mean)
In coding, unless you're doing dependency injection, we generally make each module in charge of declaring their own dependencies. If, for example, I'm wishing to import and use an internal logging module, I shouldn't have to worry about what it depends on to write these logs. It might just use node's fs module, or an npm package, or maybe it sends logs over the network, I don't really care how it logs, I just want it to do its job. If at some point this logging module switches to using an npm package, I shouldn't have to change a single line of code outside of the logger. These are how "static dependencies" work.
Sometimes a module/function requires "variadic dependencies". These are dependencies that vary depending on the current context. Currently, we just call these dependencies "parameters" and treat them as such, but doing so can lead to some nasty issues. Let's go back to our logger example. We decide to make a change to how logging works, and wish to link logs to the request the log happens in, That is, each inbound request will be assigned a randomly generated request ID, and each time we log something out, that request ID will get logged with our message. There's currently only one way to achieve this desired effect - we've got to update every single intermediate function between where the request is received and where logging happens, and add the request ID as a parameter. These intermediate functions shouldn't care whether or not logging wants to use a request ID or not, this kind of change shouldn't be something that requires updating half the codebase. With function call contexts, this request ID can be treated as a variadic dependency instead of a parameter, and we only need to update two places to provide this dependency - the logging module, and a file where we can inject a bit of code that runs with each request, which will provide the request with a function call context.
For prior art, there's actually a good number of places where this concept has been put into practice (albeit in different shapes). React contexts are an obvious shining example, but there are other subtle ones too. For example, here's a code snippet showing how to use Python's flask library:
from flask import request
myParam = request.args.get('myParam')
Notice that the request parameters are not being passed into the login function? Flask is able to automatically detect which request is currently being handled. Many frameworks provide this kind of functionality.