Really? I know pip does it by default if you don't use virtual envs, but that's related to how pip works - activating the venv basically swaps pip/python executables and `site-packages` to the ones in the venv directory. I admittedly can't think of another I used where that's the case (none of cargo, go mod or npm/yarn/pnpm install globally by default). I admittedly did not really try others enough to notice how they work.

Still, the end-goal is not the same, IMHO. Outside exceptions (e.g. some developers not packaging their applications and making users install through `pip`/`npm install -g`, which I also really dislike), your typical end-user would not interact with language specific package managers. They're most typically used for development/deployment dependencies, not end-user installation.

Go's not technically global but the path of least resistance is to use it as if it is. You'll only notice the difference on an actual multi-user workstation, or if you take extra steps to get a per-project package directory.

Rubygems is usually global.

The granddaddy of them all, CPAN and its cpan install tool, defaults to installing globally, in practice, on most systems.

Pip, as you noted, does it.

I think Maven's typically user-scoped, so not really global, but also not project-scoped like npm. Similar to Go.

You can get around this in most or all cases—sometimes with options or config, sometimes with extra effort or some aliases or scripts, sometimes environment variables, sometimes with 3rd party tools—but the simplest or default mode is global installation, or at least project-global if not user-global in Go's or Maven's cases. And many of those solutions (e.g. rvm) still don't scope installation per-project by default, like npm does.

At the time npm got started, especially, it was definitely an outlier in its default scope. Some others have taken its approach since, and maybe a majority of total language-specific package managers even do, these days, but adjusted for actual use in the wild, I bet NPM's by far the most-used one that operates that way, and that most of the other popular ones scope more broadly—including, often, globally—by default. That is, a language-specific package manager one runs into in the real world, in 2022, usually isn't going to scope packages like NPM does without some extra effort. Global or per-user scoping (the latter being functionally identical on any single-user machine) are more likely.