And I can also envision that certain packages might not get updated, necessitating a fork to patch them for M1.
I’m interested in how homebrew and others will handle that (so official package x chooses not to patch/accept a patch for whatever reason, leading to a fork of package x with a patch applied), presumably to avoid namespace collisions/not giving the user what they want, there could be an error message that states that an ARM64 version doesn’t officially exist but links it to the fork and gives the option to install that instead. And then there could be a flag to always allow linked-replacements if an official patch doesn’t exist.
If you want to regain my trust, remove the analytics function, swear off such things forever, and expel Mike McQuaid from the project. But I doubt that will happen, so MacPorts it is. And I'll encourage everyone I know to use it rather than Homebrew.
One thing I still want to point out though: whatever we do, we do it in good faith and with the best of intentions for both our users and ourselves.
Given that policy I would assume that such a package might die until somebody forks it and takes on responsibility for maintenance.
Homebrew is about building and installing upstream packages, not about installing and maintaining custom forks of packages.
When they are doing a bad job, they might anger maintainers ("I didn't add this bug - this was added by macports - complain to them!"), or they might introduce additional security issues not present in the upstream package (see the Debian openssl bug from 2008)
It might also mean that you're not getting the latest versions of upstream packages because adding those patches and rebasing them on top of upstream changes takes time.
Being close to upstream was a selling-point of homebrew back in the days when it was just a collection of scripts to make it easier to build original source distributions of common Unix software.