It would be nice if uses of now-gone interfaces failed at the pybind11 or C++ compiler levels, but perhaps overloading/templates makes that impossible?

In any case, it's a good suggestion that the release note saying that the interfaces have been removed make very clear that uses of them will cause problems.  Please send suggested text to Gabriele Comoretto to incorporate.

It would be nice if uses of now-gone interfaces failed at the pybind11 or C++ compiler levels, but perhaps overloading/templates makes that impossible?

It's worse than that. If I understand John Parejko's description correctly, the thing that should not have compiled was calling convolve(OutImageT, InImageT, KernelT, bool) when the only remaining overload is convolve(OutImageT, InImageT, KernelT, ConvolutionControl). It turns out that ConvolutionControl is implicitly convertable from a bool.

I think the only way to avoid this is to tighten the style guide to require explicit constructors in general; implicit construction through default arguments is too easy to overlook.

Oh, I was wondering if there was an implicit constructor hiding in there somewhere. Krzysztof Findeisen: do you mind filing tickets about that for ConvolutionControl and for updating the style guide? I agree that we should just require explicit constructors always, but I'm not sure how to best word those things.

Krzysztof Findeisen and I are working on wording to send to Gabriele Comoretto re: interface removal.

While I can't think of a case where we'd have a problem with having every constructor marked explicit, it might do less violence to the code base (and achieve compliance more rapidly) to only require it for constructors with 0 or 1 non-defaulted arguments.

For the record, Krzysztof Findeisen sent an note to Gabriele regarding the release notes and filed DM-27424 about the `convolve` implicit constructor.

Final jenkins run successful, and everything rebased and merged. Phew.