so will you explicitly need to specify 'wget2' in a package manager, or is this replacing wget. i certainly hope it's not the former!
Or, call 'wget2' to get HTTP2 support. You can then either install both 'wget' and 'wget2', or the package maintainers could install a symlink for 'wget' backwards compatibility, so you'd only need to install the newer 'wget2' package.
From the package maintainer's perspective, they're literally different software projects, and changing an established package name to be different software would break many systems.
That's not really an acceptable change... Would you like all the scripts you run on your Linux distros to break every time you do package updates? I wouldn't touch such a distro with a 100 foot pole
On 1) a rolling distribution not called NixOS 2) which mindlessly installs wget2 3) and does not use their own power to install or name the binaries according to their own view, sure 4) nor use a grace period and badly informs the user(s) which something like Homebrew would... then yes, it is a problem.
On a distribution which has stable and LTS releases such as Fedora/Ubuntu/Debian it is no problem as long as users would read the release notes.
It could be a problem on Arch and Gentoo, but whenever those users run into trouble you could argue PEBCAK or go fix it yourself. Same for those running -CURRENT on *BSD.
Over time, the wget binary will be replaced with wget2. The transition should happen smoothly and slowly the same way as the gpg -> gpg2 transition happened.
Source: Am maintainer
wget() { wget2 "$@"; }
alias wget=wget2