Why can't extensions contribute substitution variables for usage in tasks.json, etc.?

[LostTime76]

I have been searching within the issues and there seems to be several orphaned issues requesting a similar feature. That or a compromise was reached that doesn't really address the issue. If I am mistaken and the feature already exists, then kindly direct me towards the page describing it. I am not saying that there are not ways to achieve what I want already; however, the existing ways are not very user accessible.

Here is the use case. I want to make an extension that has several configurations. Within each configuration, the user can define their own custom variables that can be used elsewhere within that configuration using known ${var} vscode syntax. It would be nice if there was an api to resolve the strings containing ${var} substitutes and also allow their usage within tasks.json, etc..

These are not static variables known at extension build time. The variables are user defined and each configuration could have an entirely different set of variables.

I discovered the newly added environment variable api, which would allow me to set / unset environment variables when the user selects a given configuration. Awesome. Non starter: When the environment variables change, it triggers a warning in all open terminals 'requesting' the user restart them, because their environment blocks changed. Understandable. The issue is that I don't want the user to voluntarily have to restart all of their terminals. If they forget to or outright do not, newly updated variables won't take effect. Maybe some sort of refresh all terminals api ? I don't find this very conducible, because I think it will cause a large UI hiccup unless the processes can somehow be hidden / restarted in the background without affecting UI.

Today you can use ${command} inside tasks.json. There were various requests to allow arguments within the command, and seemingly reluctantly the team provided the argument ability within the 'inputs' section of the configuration. This is a flexible way of doing it and can achieve the desired functionality. However, the user can have many variables set. Having to repeat an input block configuration 10 times for example just to pass a specific argument to an implemented extension command such as ${command:myext.getVar} is extremely cumbersome. It also does not fall in line with the ease in which users can already today use variables like ${file}, ${workspaceFolder}, etc..

I think extensions should be able to contribute substitutable variables at runtime. The existing mechanisms do not seem very user friendly. We can muck about the syntax, but ideally it just ends up being ${user_var} and not ${myext:user_var}.

Well known platforms such as Eclipse have supported this variable feature since time immemorial. I am a huge Eclipse hater after being forced to use it for most of my career for C development. However, comparing to alternatives, there do actually exist a few things it got right such as variable substitution. For example, in a c++ project, I can literally go to the "variables" section in the active build configuration. I can define any variables I want and then use them anywhere else in strings to construct paths or whatever I may need. Super simple, super easy.