Entirely inappropriate. As a distributable system component, the
prerogative for modifying this file lies with the project maintainer.
I assumed /etc as a configuration dir, therefore modifiable like in true unixes. Actually, now I wonder how exactly it is there, when updates take place. I remember for example, seeing diff dialogs when upgrading Ubuntu for files in /etc that I hadn't modified myself, but I think they have somehow annihilated such end-user insanity these days.
Anyway, point taken. However, how about /etc/fstab? My customizations weren't overwritten for this file.
4) If user-specific customisations aren't sufficient, add a custom
hook script, (or more than one, if you prefer), in /etc/profile.d;
(anything you place here is your's to maintain, in perpetuity,
and will be sourced by /etc/profile at login shell invocation).
I have moved the timezone script to that directory, and it worked fine except that we need to add the .sh extension.
Well, each to his own; I would always prefer the MSYS "find" to the
crippled ersatz "grep" which Microsoft call "find" :), but I would
most likely have used $HOME/.profile or $HOME/.bash_profile, to
implement a start-up hook such as this.
I took a look at the Windows setting for PATH, and it was actually for avoiding duplicated items, because I had moved the MinGW/MSYS bin items to the Windows setting for PATH, so that it is MinGW/MSYS, actually, that takes precedence over Windows utilities with same name, when using cmd.exe or similar. That was also for having MSYS utilities available outside bash in general, for example not just cmd.exe (if I'm forced to use it for any reason, e.g. for applying the announced update) but also from shortcuts, scheduled tasks, etc.
So yes, Windows' find is horrible, and I think using sed or similar to remove duplication from PATH would be uglier than just ignoring it:
/bin => this and above come from /etc/profile
/usr/local => this and below come from Windows