There’s a decent argument for reproducibility here. Even if we reach Julia v5, there’s no inherent reason that a registry of v1 packages shouldn’t keep working for v1 code. That registry just won’t be the default one by v5 anymore, even if something like Pkg still exists by then. I just don’t think it’s reasonable for someone to activate a properly designed environment from 5 years ago just to find that some obsolete dependency was removed, or worse, silently replaced by a totally different package’s overlapping version numbers. So maybe repurposed package names start at a higher major version?
Note that packages are already deregistered for higher Julia versions without compromising reproducibility. That’s necessary for obsolete packages that specified unreasonable upper bounds of dependencies yet used unstable internal names that eventually break. I’d think that stricter upper bounds in the project are only proper for packages that use internals, but that doesn’t always happen and action needs to be taken on the registry side. I’m not even sure if it’s possible to fix a mistaken upper bound on the repo side; wouldn’t a patch just be ignored by Pkg for the unpatched upper bounds?
On the other hand, there may be reasons for complete removal at the cost of reproducibility. I don’t really know the details of copyright, but keeping a package that violates licenses in a registry would poison projects of further users and might not be legal. Maybe LLM-assisted coding doesn’t need to be a direct factor in judgment, but it’s worth recognizing the heightened risks.