The way I see it, this problem is not a real problem, it's extremely artificial.
You will get all the tokens as is regardless of the platform, there's nothing that stops you from using "posix style arguments" on Windows. Or use / for unix systems, sure in some situations arguments might be confused by absolute paths
on that system (if paths are used unconstrained), but you can write a well-defined application (even a portable one) in this way.
Of course, to a certain extent you will eventually need to deal with platform specific things like how to handle paths, but the size of zoo in which platforms differ in this regard is much smaller than the zoo of "how do I get application
arguments outside of main" for any particular platform, and much more easy to manage.
If the standard provides a facility to give you these arguments, you would still have saved developers a lot of work to not have to figure out how to get the argument list outside of main for every single platform.
The argument isn’t about could it still be useful in a world where we have multiple platforms that interpret arguments in a slightly different fashion, but “how much” in light of how we actually use these things.
Application arguments are arguments relating to (well) how you interact at the application level, hence why it is generally in the interest of the developer who writes “main” in their application to be the one parsing these arguments, and
maybe propagate the already passed arguments to other subsystems.
There may be subsystems that might be interested in parsing command line arguments where the alternative of them not being forward from main is not a viable solution, but they are exceedingly rare.
One notable example mentioned was diagnostic purposes, but in that case, you would be interested to retrieve this information in its purest form, i.e. the same way the application has received it from a parent process, and you wouldn’t
want that information to be tainted by an interpretation layer to tokenize the arguments as that may lose important information regarding how the application arrived at its current state.
The other application is… I don’t know of any.
There is perhaps another argument that might not be considered here.
Deprecating “main(int argc, char** argv)”.
As mentioned not all platforms receive information from their parent application in this form, and involves code to be executed before main in order to present data in this way.
Your application is assigning resources to deal with it, and even tough you may only need it at the very start of the application, those resources remain unused and unclaimed for the entire lifetime of the application.
Making “main(void)” the default, means you don’t need to allocate resources if you don’t actually need them. This facility would still allow you to use application arguments, but the resources are only allocated when the user decides it
wants them, and can release them when no longer needed. Making applications run more lightweight by default.