Running Apple Silicon and x86 homebrew side by side, cleanly

_TLDR: I am aware that there are plenty of questions from people trying to migrate from Intel to Apple Silicon installations of homebrew; and many questions that speak of confusions from unwanted conflicts between those. This is not about that. This is about running two installations side by side and avoiding any mixing or involuntary confusion between the architectures._ ## Background I am setting up a brand new 2024 MBP, and so far all is going well. I am coming from an Intel MBP. I have installed brew (on the new machine) from scratch, fully native, with the evil "curl" method directly from https://brew.sh . I dumped my Brewfile on the old machine, and installed all the packages I had on the new, from that. This successfully pulled all the native versions of the packages and installed them in /opt/homebrew as advertised. I also used rbenv, installed via brew, to build some version of ruby that I need for a project. This also worked completely as expected with no hickups whatsoever, since all dependencies that rbenv or rbenv install needed were already in my Brewfile. _I have copied *nothing* from the previous MBP directly._ I am 100% certain that there is no confusion with some old architecture binary slipping onto the new machine. Nothing in /usr/local/bin has been copied. ~/.rbenv has not been copied. So far so good. Unfortunately, it turns out that a single gem that I need for that project, and which has a requirement on a closed-source binary from a vendor, is not yet available for Apple Silicon. I cannot get rid of that gem, but using it with the silicon version of ruby is just not on the table yet. ## Question While waiting for the issue to resolve itself, my thought is this: is it possible to install an Intel architecture version of brew (and subsequent tools like rbenv and the shims provided by it) in /usr/local/bin which is *completely* separate from the Apple Silicon version in /opt/homebrew, and which is by default also disabled (by virtue of the path not being in any environment variables)? Fortunately, I do not require rbenv or ruby to be available in both installations; I only use it for that single project. It would maybe be cleanest to have a script that I can source in a bash which sets a bunch of variables, and from then on, in that particular process, the /usr/local/bin environment would be active, and the /opt/homebrew environment would be hidden (i.e., maybe take /opt/homebrew out of all $PATH etc. variables). I am aware that the extended installation docs of brew describe how to install multiple versions in arbitrary directories. I could not find any mention of my usage scenario in the documentation or the brew github issues though. Am I setting myself up for disaster, or is this known to possibly work well (even if unsupported by brew, as stated clearly)? What would the required environment variables? Is it enough to just prefix any bash or other command I intend to run with the Intel versions with arch -x86_64 ... and make sure /opt/homebrew is not in any variable? If I start a bash with arch ..., does that architecture choice automatically get passed on to any subprocesses (i.e., when running brew, rbenv, and shims like ruby, cucumber etc.) or are there known cases where this setting somehow gets lost? The reason why I think it would be best to start with brew and not only arch'ify rbenv itself is that there are a few dependencies that rbenv needs to compile ruby, and *those* are easy to install with brew. Hence I could avoid having to completely manually install any dependencies of rbenv, ruby or some of the more "intense" gems. ## Bonus question As mentioned before, I would accept if the two brew environments are completely separate, and only one is ever "on" at any given time. Would there be a way to have them both active at the same time (i.e. both in the PATH), maybe making sure that the installation directory of the currently "active" brew is first in PATH and other variables? Or is this scenario definitely out, as being much to risky?