>> C++ is an object-oriented capable language.
>> std::arguments could be a class, with a constructor that does stuff.
>> It would solve a lot of design problems.

>This is possible and it may be sensible. One nice benefit would be the user could control the lifetime of arguments object, if allocations are needed. The main concern that would come to mind for me is redundancy with multiple parts of a codebase creating their own arguments object and different parts of the code could see different arguments, e.g. if one std::arguments is used before main, then main changes argv, then somewhere else makes a new arguments object. (This is mainly a concern if it's decided it's undesirable to leave std::arguments in the case of argv modifications unspecified)

Although this may be a concern in theory, it may not actually be one in practice. For example on windows you would use "GetCommandLineW" which gets you a string that you are not supposed to modify, even if the program changes argv, that argv has no relationship to this data. On Linux I prefer to read from "/proc/self/cmdline", not entirely sure if this is modifiable at runtime, this is where my lack of knowledge of the OS fails me, but I think it's quite reliable (although I feel like there should be an alternative special address for this). And even in case where it is modifiable, there must be a way to reliably access it anyway. So, whatever those rules are, it's a platform detail. Give it an object, if it needs to allocate, you would probably would always needs to allocate anyways, if it doesn't the object can simply have no internal state and it's methods can just grab a global view of something instead.
If there's a cost to be paid, let the user decide when to pay that cost by instantiating the object (which probably will only be used once in the entire application anyways, optimize for sharing probably not a concern). What it needs to do, it’s a platform detail, let library implementers worry about that.