Pathing in the D ecosystem is generally broken (at least on windows)

[Manu via Digitalmars-d]

I update DMD yesterday, it couldn't work out where it was installed
and the uninstall fails, then complains and errors when trying to
install over the failed uninstall, requiring manual intervention.

Then I try and build with LDC, it can't link anymore because paths are
messed up and when looking for link.exe (microsoft's linker) it finds
optlink link.exe instead.
I tried to use a tool in VisualD which disassembles some code, but it
can't find the tools it needs to do the job!

This is silly. I don't know how such simple things can be so consistently hard?!
My first and most frequent problems with the D ecosystem were pathing
issues, and that's still more-or-less the case today.

It's been 6 years for me. I'm getting tired. Can we please make an
effort to get the paths right? This might mean some intelligence is
required to make it work; check if the tool is the right tool? If it's
not, keep looking? If tools can't be found, produce a dialog box
prompting the user to supply the proper path to the tool? MSVC
interaction (DMD-COFF and LDC) should probably leverage Microsoft's
command line scripts, which are located in reliable places, and work
reliably. MSCV associated tools shouldn't be capable of finding
optlink by mistake.

As a rule, no tool should ever require a windows user to interact with
their path variable. It's a colossal mess, windows doesn't do 'PATH'.
Mine has an endless list of bin directories, and many/most of them
provide duplicates of the same programs. A robust program can never
rely on PATH.

Here's a typical PATH configured for the tools I use in my office:
%QTDIR%/bin;%LDC_ROOT%\bin;C:\dev\wxWidgets-3.0.2\lib\gcc_dll;C:\dev\CMake\bin;C:\dev\LLVM\bin;C:\Program
Files (x86)\Microsoft VS Code\bin;C:\dev\Python27\;C:\Program Files
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS
Client\;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program
Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files
(x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files
(x86)\Intel\Intel(R) Management Engine Components\IPT;c:\Program Files
(x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program
Files\Microsoft\Web Platform Installer\;C:\Program Files
(x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\;C:\Program
Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files
(x86)\Windows Kits\8.1\Windows Performance
Toolkit\;C:\dev\dub;C:\dev\Emscripten\clang\e1.27.0_64bit;C:\dev\Emscripten\node\0.10.17_64bit;C:\dev\Emscripten\python\2.7.5.3_64bit;C:\dev\Emscripten\java\7.45_64bit\bin;C:\dev\Emscripten;C:\dev\Emscripten\emscripten\1.27.0;C:\dev\Emscripten\crunch\1.03;C:\dev\Emscripten\mingw\4.6.2_32bit;C:\Program
Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Program Files
(x86)\Git\cmd;C:\Program Files (x86)\Microsoft
SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL
Server\120\Tools\Binn\;C:\Program
Files\TortoiseGit\bin;C:\dev\D\dmd2\windows\bin

This is minimal compared to my home dev environment (ie, is a
controlled office PC).
Surely this is evidence enough to conclude that no tool should *EVER*
refer to PATH to find tools?

The installer should remember where it installed last time!

This requires action from every tool in the ecosystem, to include a
little bit of logic that allows it to validate that paths are
configured correctly and that the program _works_, and do something
useful or ideally *helpful* if they're not.