The key question for me is whether this "advanced flow" will allow the practical use of entirely separate app stores (like F-Droid) or if they're going to throw up tons of barriers for every individual app install.

If I were designing the advanced flow, I'd require the decision to be made at phone setup time. Changing your mind later requires a factory reset.

Real sideloaders (F-Droid users, etc.) know at setup time that that's how they'll be using their phone, so it works for them. But ordinary users who are targets for sideloading malware will become a lot less attractive if attackers must convince them to wipe their phone to complete the coercive instructions.

Aliexpress has a similar approach to protect their accounts from takeovers. If you change or forget your password, all your saved payment methods are erased. This makes the account less valuable to an attacker, at the cost of a little pain to authentic account holders.

There's a second path, whereby F-Droid registers as an "alternative app store", which is a new category of app created in the fallout of Epic Games v. Google [0]. This is interesting because it applies to all regions and will necessarily need more elevated permissions than the typical REQUEST_INSTALL_PACKAGES permission used today. No idea what requirements Google will impose on such apps.

[0]: https://en.wikipedia.org/wiki/Epic_Games_v._Google

If F-Droid is no longer part of the android community, then neither will I.

I'm not too worried. My employer should be, though.

It all depends on how the flow is implemented.

If it's a one time unlock, eg like developer mode then hopefully it'll just work.

If it's a big long flow per install... Yikes, that's not much better than adb install

Correct me if I'm wrong but doesn't the EU digital markets act mandate this?