The reason why it's not quite so simple is because any existing API that uses TCHAR[MAX_PATH] would be ABI-broken. Some of them are obvious, e.g. the WIN32_FIND_DATA struct used by FindFirstFile/FindNextFile.
The less obvious part is that for a very long time, it has been a contract for all Win32 functions that return PATHs, that the maximum size of the returned path is MAX_PATH. So there are a lot of apps that basically allocate a buffer of that size and assume that it'll always be enough. So functions like GetFullPathName can't just start returning longer names, because it would break those apps. Instead, they rely on the presence of "\\?\" prefix in the input path as an indicator that the calling app understands those longer paths, and is ready to accept them as outputs as well.
I agree, but there are two different issues here (1) \\?\ to bypass the maximum path length limitation; (2) \\?\ to bypass the reserving of file names for devices
You are talking about (1), and I agree it has some problems, yet Microsoft already has an EXE manifest option to bypass maximum path length without \\?\.
Whereas, I am proposing (2), which could exist without (1). They could add an EXE manifest option and/or registry key to tell the Win32 API to ignore bare device names, or device names with extensions, when converting Win32-to-NT paths, even while keeping the MAX_PATH limitation. So you wouldn't need \\?\ to access a file/directory with a reserved device name. But you might still need it to access a long path. The two issues are orthogonal and could be controlled by different settings.
The less obvious part is that for a very long time, it has been a contract for all Win32 functions that return PATHs, that the maximum size of the returned path is MAX_PATH. So there are a lot of apps that basically allocate a buffer of that size and assume that it'll always be enough. So functions like GetFullPathName can't just start returning longer names, because it would break those apps. Instead, they rely on the presence of "\\?\" prefix in the input path as an indicator that the calling app understands those longer paths, and is ready to accept them as outputs as well.