Clearly we disagree on that.It is extremely relevant.
Let's suppose it did as you suggested, and now we added a transcoder (which is yet to be made progress on), What happens when the input cannot be transcoded to utf8? (which is currently possible on all operating systems).
I mentioned earlier that the proposal needs to address how transcoding errors are handled.
I don't see any other thing that the application could validly do at that point other than silently fail and exit.
Other options include replacing invalid code unit sequences with
substitution characters.
When previously this was never a concern, now there's a category of inputs that is perfectly valid to spawn applications with but invalid for your application to run with.
It is perfectly possible to spawn a process with command line arguments that are not validly encoded, encoded for an encoding other than what the program expects, or just plain not text. The transcoding layer doesn't introduce a problem that wasn't already there; it just applies an error handling mechanism of some sort for certain error conditions.
The proposal doesn't include deprecation of the existing main() signature. This would be an opt-in feature only suitable for use in situations where the programmer deems its error handling mechanisms as suitable for the program.
Programmers are always free to reject input that doesn't meet
program specifications in whatever way they feel is appropriate.
I would argue that it is a requirement of the standard library to facilitate access to files by whatever name they are given. However, an application need not provide support for all such names. I don't find it unreasonable for a program to require that files it works with have a name that is uniquely representable in UTF-8.
But let's say you don't like making applications that immediately quit as soon as you start them, and you would try to define some fail over behavior like filter out invalid input or replace offending codepoints with a placeholder. In that case you better hope that the offending input isn't a path to a file, because in that case there's no way your application will be able to access it.
It all sounds good until you have to solve practical problems.
The proposal as offered does not match my preferred approach.
Personally, I favor an approach that facilitates both raw access
and access in common Unicode encodings with error handling
facilities. I'm just pushing back because I don't find the
arguments you have presented against the solution proposed in this
thread compelling or relevant. The only way in which the Unicode
Standard is relevant to this proposal is that it defines the UTF-8
encoding. If you were to substitute a non-Unicode encoding for
UTF-8 in what is proposed, then the Unicode Standard would be
completely irrelevant.
Tom.