Homebrew installs in /usr/local, not in /usr, and OS updates never touch /usr/local. And if you're paranoid, you can instruct Homebrew to install somewhere else instead.
That's not entirely true. A relatively widespread issue during 10.10 (Yosemite) updates was the installer seemingly locking up and actually moving all the files in /usr/local one by one to then from a backup location veeeery slowly, potentially taking >12h to complete the update rather than a pair of.
I heard people mentioning that (for 10.11 btw, not 10.10), but I never saw anyone give any reason for believing that that's what the installer was doing. Furthermore, I had a pretty extensive /usr/local Homebrew installation and my update to 10.11 completed in the expected time.
Besides, even if the installer did do that, the resulting updated OS still had all the same contents in /usr/local.
As far as I'm aware, the only change OS updates have ever made to the /usr/local folder is resetting permissions back to root:wheel.
> I heard people mentioning that (for 10.11 btw, not 10.10), but I never saw anyone give any reason for believing that that's what the installer was doing.
And it was for 10.10. I'm sure people who'd been bitten (or had avoided it through the procedure above) repeated it for 10.11 reflexively or just in case, but the issue was the 10.10 upgrade.
Huh, I only ever heard people mentioning this issue for 10.11. Never heard about it at all when 10.10 came out. I bet that's why I never saw any explanation for this reason, because people who had heard about this with 10.10 were just assuming that's what was going on.
Incidentally, I had no idea about ⌘L to show logs during OS update.
In any case, even if the OS update takes a long time, the end result is you still have the same /usr/local you did before.
Also, FWIW, the discussion you linked to references TeXLive, as does the blog post you linked. I wonder if the issue here is not in fact having anything in /usr/local, but rather having used a package installer to install something into /usr/local (which I assume TeXLive does). It doesn't make much sense to me for the OS updater to move everything out of /usr/local and then back in one-by-one under normal conditions. But if you used a package installer to install into /usr/local, then it would make more sense for it to do something like that (which is to say, it may have special behavior around things covered by package receipts).
Edit: Well, under normal conditions, it might still move the folder away and back, but I'd expect it to just move all the top-level items from the folder back, instead of manually copying all of the nested files).
It's a good idea to install elsewhere, because there are other packages that install into /usr/local (TeX, for example) that aren't in homebrew. I like having my homebrew installation totally separate -- I feel significantly more comfortable upgrading my software to bleeding edge versions if there's no chance of some non-homebrew brain-dead configure script grabbing them. I install to ~/.homebrew, and everything works fine for me. Of course, I don't use ruby at all, or install Python or Emacs packages via homebrew, so I haven't had any of the problems that the homebrew folks warn about on their installation page.
The reason that Homebrew defaults to /usr/local is because there are a lot of braindead packages out there that hardcode the possible locations for software (e.g. /usr/lib and /usr/local/lib), and if you install Homebrew somewhere else, you can't use Homebrew to satisfy the dependencies of any such braindead software you come across.
However, if everything you're installing that depends on Homebrew-provided software is also installed through Homebrew, then it should work regardless of location (I say "should" because I suspect that not every single Homebrew formula has actually been tested with a non-/usr/local install path).
Personally, I stick with /usr/local both because I've never had a problem with it, and because that makes it easier when working with software that uses a default PATH (since /usr/local is usually put in these default PATHs). But if you have any concerns whatsoever, then by all means use a different install prefix.
That's a really weak justification. For most of those "braindead" packages, it is actually fairly easy to get them to install into arbitrary locations. After all, both Fink and MacPort have been doing that with great success for over a decade.
Sadly, you are correct about "not every single Homebrew formula has actually been tested with a non-/usr/local install path". In fact, while there are many Homebrew formulas of great quality, my impression is that there are also m many of rather poor quality, with other problems in them. E.g. just yesterday, I discovered that the Homebreak lmdb formula does not build properly versioned shared libraries -- because upstream didn't, and the packager either didn't notice or didn't care to fix it
I rarely (if ever) this kind of issue with MacPort and Fink, which try hard to avoid such problems (at the cost of a higher entry barrier for packagers -- for better or worse). Mind you, I am not everything is golden with them, either.
Disclaimer: I've been involved with the Fink project since OS X 10.1 or so.
That's not entirely true. A relatively widespread issue during 10.10 (Yosemite) updates was the installer seemingly locking up and actually moving all the files in /usr/local one by one to then from a backup location veeeery slowly, potentially taking >12h to complete the update rather than a pair of.