apt cancels holds on uninstalled packages

This is not a bug in apt. dpkg cleans up its database and removes hold states for non-installed packages following an operation.

Whether it's a bug in apt or in something used by apt doesn't really make a difference from an end user perspective. Can this bug be reopened as a dpkg bug, then, or should I report that as a new bug?

You're right btw that it's a dpkg bug, but it's a bit more subtle. The cleanup that dpkg performs after installation is meant to preserve the hold state for non-installed packages. This is handled by the pkg_is_informative function, which classifies everything with "pkg->want != PKG_WANT_UNKNOWN" as informative, so would actually preserve hold for non-installed packages. However, pkg_parse_verify contains logic to fix up state left by older dpkg versions, without taking into account that this also includes valid state by current dpkg versions:

  /* XXX: Mark not-installed leftover packages for automatic removal on
   * next database dump. This code can be removed after dpkg 1.16.x, when
   * there's guarantee that no leftover is found on the status file on
   * major distributions. */
  if (!(ps->flags & pdb_recordavailable) &&
      pkg->status == PKG_STAT_NOTINSTALLED &&
      pkg->eflag == PKG_EFLAG_OK &&
      (pkg->want == PKG_WANT_PURGE ||
       pkg->want == PKG_WANT_DEINSTALL ||
       pkg->want == PKG_WANT_HOLD)) {
    pkg_set_want(pkg, PKG_WANT_UNKNOWN);
  }

We are now at dpkg 1.20.x, well after 1.16.x. If this block of code is removed (or at least the pkg->want == PKG_WANT_HOLD condition), direct installation by dpkg works as expected, and presumably installation using apt will work as expected as well.

Yes, but that's really something for dpkg upstream to look at, and not something we should patch out downstream.

I didn't remember the discussions with the dpkg maintainer about this, but I did find them now, and he basically pointed at the same thing.

Anyway, this is not a common use case, so there's no point adding an extra delta here. Use pinning in apt instead.

My understanding of pinning is that that can be used to specify which version to use, which is what I use it for already, but not to force no version to be used. Agreed that this is not a common use case, so low prio and not patching it till it's fixed upstream makes sense, but since it's something I don't have a good alternative for, I have locally just built a modified dpkg to get this working properly.

Sure you can keep versions away with pinning, you pin them to negative values, e.g.

Package: idontlike
Pin: version *
Pin-Priority: -1

Huh, so you can, thanks. Confirming that this works too, and agreed that that looks like it should cover all cases.