Some anecdotal evidence re: whether jbuilder-beta18 was used by anyone:
Breaking jbuilder just before the mirage retreat (where everyone updates their system because the network in Morocco is limited) was definitely a source of some frustration, and quite a lot of debugging turned out to have “oh you’re using a broken jbuilder release” as its root cause. But alas that is the way it is with beta software, there will be broken things. It sounds like the building of dependencies / reverse dependencies (recursively/transitively) mentioned above might be a good thing. 
I think there are many good points in this thread raised by everyone, and thanks to @Joris for explaining the details of how yank works in the Rust ecosystem.
Just for good measure, since it has gone unadressed, I’d like to make an argument against letting people remove versions from opam. Doing so would:
- break pinned dependencies
- make it harder to do reproducible builds, checksumming, signing, CI, anything that rests on the assumption that a release has a given hash and is immutable
- for example when you later reintroduce a new software release with a different version number (meaning we have to come up with a new coordinate system for
xxx version 1.02, version [1,2,3,4, ... yanks+1])
- for example when you later reintroduce a new software release with a different version number (meaning we have to come up with a new coordinate system for
As I see it there is one way to do this that doesn’t introduce any extra complexity: Bumping minor version and re-releasing the old package.
An alternative that comes with some complexity, but yet is still fairly viable, would be to change the OPAM metadata for the broken release to be uninstallable, as suggested in comments above. I think this is the most practical solution.
PS: I’m a fan of the discussion of overlays and debian-testing-like overlays on top of OPAM for the brave and hungry.