For reference, #118442 is related in that the original idea we were hoping for was optional dependencies, such that Python could "depend on" Pylance in the traditional sense, but that it could be uninstalled later without repercussions. The extension pack method is an in-between solutions, but that did lead to oddities like #128088 as it doesn't impact activation order or "waiting" for deps.

To restate our intentions here:

• Pylance depends on Python, but only from the point of view that the Pylance extension itself doesn't do anything without the Python extension. It does not require the Python extension to activate before it, just be present, so we mark it as a hard dep so that users searching for "Pylance" aren't wondering why it doesn't work.
  • We can drop this hard dep in favor of prompts or some backup client in the future.
• Python optionally depends on Pylance, so we can use Pylance if it's there, and fall back to other options otherwise.
• When installing the Python extension, Pylance is also installed, so it can be the default for new installs.
• The Python extension is able to see that Pylance is installed during activation, so it can know it does not need to fall back on a different LS.
  • It would be best for Python to activate quickly, then get this info some time later, but the Python extension already can't tell that some extension is going to be installed in the near future.
• Eventually, the Python extension will activate the Pylance extension to gain access to its API. This does not need to be during the actual activation chain, just sometime in the future.

@jakebailey IMHO, based on what you describe, Pylance should have simply been an integral part of Python and not a separate extension. That's what we do with virtually all other language extensions, they typically embed inside of them the language server(s) they use. User facing settings and commands can then be added to delete Pylance from disk or to stop using it if the user wishes to not accept the Pylance license.

So IMHO all of this could have been implemented as 1 setting or as 1 command with a much lower development cost and effort.