It's been fixed for 8 years. In the OS that is. If apps still hardcode 260 then that's their problem.

The background is that Microsoft strives for backwards compatibility in its operating systems from 40 years ago until today. Not saying you can execute native 16bit apps on Win11 out of the box, but the pathways are there if you have an MSDN account 🎉

They did. Starting with Windows NT the OS supports 32767 UTF-16 code-points long paths, but you need to use special prefix, otherwise backwards compatibility keeps the limit of 260 characters. Starting with Windows 10 version 1607 the application can opt-out of that backward compatibility and use 32K long paths freely.

As others have mentioned, Windows has the ability to bypass the 260-byte limit. But it's not enough for the operating system to add new functionality. The core challenge is getting the ecosystem updated, because it requires special considerations for applications. Even though Windows has had the ability to bypass the 260-byte limit for years (decades?), applications are slow to react. A large part of the reason for this is that application developers often target versions of Windows like Windows XP and Windows 2000, and those operating systems don't have many of the nice features that are added in newer versions. And maintaining applications that can work on both old and new operating systems is made easier by just targeting the API surface of the old version of the operating system. And the problem is pervasive. There are even many Microsoft applications that don't yet fully support long filenames.

Oh, and to be fair, I was just thinking about answering the question as asked, and not including a forward looking addendum - that was an oversight on my part, I should have included it.