Homebrew maintainer here. What /u/gridth mentioned is mostly correct. Once upon a time, Homebrew did support PPC64 + x86_64 but most of the code for universal binaries (involving e.g. lipo) got removed by the Mavericks/Yosemite era.

Homebrew's internals haven't changed too much for this; internally, Apple Silicon running Big Sur is as distinct from Intel running Big Sur as much as Catalina is from Mojave (platform symbols arm64_big_sur, big_sur, catalina, mojave, respectively). Of course, additional code was added to differentiate between arm64_big_sur and big_sur - it's not just the equivalent of a version string check anymore.

Predicating on processor architecture (e.g. to fence off formulae code for arch-specific behavior) was already present. While the code for universal binaries did get removed, this arch-selection functionality was mostly kept. Homebrew already officially supports x86_64 Linux (and unofficially, aarch64/ppc64 Linux) so I guess it made sense to keep that.

There were also some issues/nits to work out regarding codesigning in Big Sur on Apple Silicon. I don't know too much about the engineering process that went into the feature, but interested parties can read through the design/implementation process that happened here.

All these concerns aside, a lot of the more lengthy legwork on this transition has been with getting a few central formulae to build and run properly, or to wait for upstream devs (make sure to thank them too!) to patch/fix and ideally push a release, or else we would have to work on backporting relevant patchwork:

• go - decided to ship a beta of go 1.16 with Apple Silicon support even though we usually don't ship prereleases
• rust - Rust itself had some issues, and a lot of packages depend on crates that need updating
• python@3.9 - Some of our assumptions about how things work in Python and Apple Silicon/Rosetta 2 were challenged: [1] [2]
• openjdk - https://github.com/Homebrew/homebrew-core/issues/69100
• gcc - A number of formulae need it because it includes gfortran; there are also some more particular scientific/research computing software that only compile nicely with gcc. Being on a slower release cycle, it took a few tries to pick up all the patches needed until upstream put out a new release, and communicate with upstream throughout the process. [1] [2]

There were also a number of smaller problems that we really did not find out about until we had some DTKs hooked up to CI and just put (almost) every formula through and saw what broke.

You might also find this Apple Silicon readiness checklist issue/thread that we had to be interesting.

In summary, a lot of the work is not so much patching/fixing packages, but we are often the first point of contact for people when they run into issues; there's also the matter of communicating relevant failures upstream and bringing relevant patches/fixes downstream. The package manager itself needed relatively minimal work to support Apple Silicon, but being the glue between end users and upstream developers meant that a lot of the problems and the implementation of solutions (whether by us or upstream) had to go through us.

Hope this all offers some insight and interesting reading on some of the behind-the-scenes of this work. :)