Holy cow, I wrote a book!
Programs that weren't designed to handle long file names
would make mistakes like taking the path to the executable
and writing it into the registry,
unaware that the path might contain a space that needs quoting.
(Spaces—while technically legal—were extremely rare in SFN paths.)
The CreateProcess function had to decide whether to "autocorrect"
these invalid paths or to let those programs simply stop working.
This is the battle between pragmatism and purity.
Purity says, "Let them suffer for their mistake.
We're not going to sully our beautiful architecture to
accomodate such stupidity."
Of course, such an attitude comes with a cost:
People aren't going to use your "pure" system
if it can't run the programs that they require.
Put another way,
it doesn't matter how great your 1.0 version is if
you don't survive long enough to make a 2.0.
Your choice is between "being pure and unpopular" or
"being pragmatic and popular".
Look at all the wonderful technologies that died
for lack of popularity despite technical superiority.
(And, in the United States: The metric system.)
I see this happening over and over again.
A product team that, hypothetically, makes automated
says, "I can't believe we're losing to Z.
Sure, Z's diagrams may be fast and snazzy, but ours gets
<subtle detail> right, and when you go to
<extreme case> their diagrams come out a little distorted,
and they're faster only because they don't try to prevent
X and Y from overlapping each other in <scenario Q>.
We're doing all those things; that's why we're slower, but that's
also why we're better.
Those people over at Z just don't 'get it'."
People are voting with their wallets, and right now their wallets
are saying that Z is better in spite of all those "horrible flaws".
Whatever part of "it" they don't get, it's certainly not the
"make lots of people so happy that they send you money" part.