Finally, it must be taught that it is unconventional and not supported by older compilers.
"not supported by older compilers" could be raised as an argument against literally any new feature.
And it specifically should not be used against this feature, because IIUC the entire point of this feature is that every old compiler already supports it.
I'm all in favor of standardizing existing practice. However, @Jan, your paper is conspicuously missing a table demonstrating which signatures are actually supported by the Big Four compiler vendors (and since what release/year they've been supported).
You mention that you don't propose to standardize signatures containing `volatile`. I think that's the right choice; but again, you're missing a table demonstrating whether such signatures are already supported in practice.
I recommend not trying to standardize `void main()` for two reasons:
(1) Returning `void` instead of `int` actually could require different prologue/epilogue codegen on certain platforms. (Adding `const`-qualification to a pointer definitely doesn't.)
(2) There is a very large body of work devoted to making fun of people who write `void main` and/or telling learners that `void main` is an even worse solecism than `using namespace std`. (Probably a significant fraction of this body of work was generated by current WG21 members, too.) You'd be proposing to obsolete all of that advice and horribly confuse newbies for decades to come. That's not just "not worth" doing; it's worth positively not doing.
I wonder whether there is any prior art for
- `unsigned main()` — this is certainly a physically compatible signature on all platforms, but does any compiler support it today?
- `uint8_t main()` — I'm less sure this is physically compatible (same as my first objection to `void main`), but it logically more closely matches how Linux treats the return code. Does any compiler support it today?