I’m not sure what kind of dependency/compilation issues you’re referring to here, could you link to some examples and maybe share some error messages? This seems like it should be fixable in the case of compilation issues. For packages that are moved/deleted, that may be a separate discussion, but this does seem like it’s happened a few times and it would be nice to have immutable releases (i.e. independent of GitHub hosting). I know this would require some additional infrastructure, though.
This idea has been explored by @dmy’s package search tool, described more in this thread:
It seems like the changes are fairly useful, but I’m not sure that it’s widely used as an alternative to package.elm-lang.org. And I’m not sure if there are any new findings since that thread, I’d be curious to hear if we’ve learned anything from that experiment.
It’s unfortunate when we have pollution in the package repository. I’m not sure there are any easy answers here, though, as deleting packages introduces a whole new set of problems which are probably worse than the problems it attempts to solve. I do think it would be nice if there was an official way to mark a published package as deprecated, though, and have a deprecation message show up similar to deprecated NPM packages. One way to handle deprecation could be to use the existing summary field in a package’s elm.json and check for a specific pattern. So if you had "summary": "Deprecated: This package is no longer maintained. Use username/package-name instead.", then the package website could display the deprecation warning for that version of the package and from the main package search. A feature like that could make it possible to add visibility to the status of a package but in a safe way that doesn’t risk installation problems due to removal of packages.