I'd like to zoom out to the overall task of packaging, first. Here, there are a lot of contributing factors.

1. Backwards compatibility concerns. Python devs hate churn in general, and the ones responsible for major projects like Pip seem traumatized by the 2->3 migration in particular (they not only had to make their own code work, but get pieces to work together in an era before "ecosystem" was even a common buzzword, and deal with complaints from clients).

2. Everyone agrees that "there should be one way to do it", per the Zen. But there is very little agreement on what's actually included in "it", and no agreement on how those tasks should (or may) be distributed across tools. Some people advocate for all-in-one solutions, others for the Unix philosophy. (My personal conclusion is that users should have an integrated tool for every common user-facing task, while devs should add to that with individual tools for individual dev tasks.)

3. The distinction between "applications" and "libraries" in Python is subtle, but hasn't been very well addressed. People have tried for years (and are currently trying again) to figure out a standard for lock files. Pipx smooths over the gap between library and application installation requirements by holding on to its own copy of Pip and using it (through perfectly well documented, but under-appreciated command-line flags) to install into specific environments which it creates (with the standard library `venv`). But while it could function as a manager for those two tools, it artificially restricts itself not to install libraries into a venv that doesn't already contain an application.

4. Python libraries have to handle a lot of extensions written in other languages. Sometimes it's necessary to compile those on the user's machine, and people want that process to be fully automated - but that leaves the problem of how to specify build-time requirements that have nothing to do with Python (for example, a C compiler).

5. The standard tools have a bunch of random limitations and flaws, and nobody agrees on what's worth fixing or how to fix it. I could probably rant for hours about this.

6. Linux distros (especially Debian and everything downstream of it) provide Python because they want to use Python to provide essential services - not so that the user can have the experience of using Python according to how the official documentation says it's supposed to work.

If you're talking specifically from the user's side: Pip and venv are still the defaults. It's worth learning how to use them better: you can tell `venv` to exclude Pip from the new environment, and you can tell a single globally-installed Pip which environment to install into. (There won't ever be any getting around understanding the concept of an environment, because if you have countless third parties offering libraries, there's no way to assure that they'll all play nice with each other.) You can ignore the system package manager completely (except for possibly installing packages to give you Pip and venv). You can make your own wrappers to auto-activate environments on some trigger, or to detect an environment based on the PWD and/or the path to the code. But I agree that there are a lot of rough edges here, which is part of why I've been designing my own competitor (no GitHub repo for it yet; I'm hoping to have something before the end of the year, but other projects are a priority for me).

If you're talking specifically about installing Python itself - as far as python.org is concerned, the standard way on Windows and Mac is to run their installer, and the standard way on Linux is to install from source using their source tarball. Tools like Pyenv are really just wrappers around this. (I can't comment on Homebrew as it's been about 20 years since I owned a Mac.)

If you're talking about choosing between installations to run, this is also pretty standard, although the standard again has flaws. I've written about this at https://software.codidact.com/posts/291616/ .