Ah, I agree that a BitwiseMovable that does not include NoOpDeinit remains interesting—this includes very common types like String and Array, at least today. What I suspect is not interesting is types that are BitwiseMovable & NoOpDeinit & !Copyable. So I'd rather have "BitwiseCopyable" mean BitwiseMovable & NoOpDeinit & ?Copyable, rather than BitwiseMovable & NoOpDeinit & Copyable, which together with SE-0427 implies that "BitwiseCopyable & ~Copyable" is a valid and useful combination.
Back in the pitch thread I tried to run through all the real-world cases, finding that they were all precedented except BitwiseMovable & NoOpDeinit & !Copyable. But we could say Swift doesn't need to distinguish all of them. What if the defining feature today was focused on the "cleanup" side rather than the "move" side? Then we could say there's two ways storage gets cleaned up in Swift at the low level: it can be moved, or it can be deinitialized. Storage that requires no "cleanup" may or may not be copyable, but if it is, that operation is always going to be treated as trivial as well.
The main problem here is that C++ does let you violate this rule, but we would say a type with a non-trivial move or copy constructor does not get the "trivial cleanup" property when imported into Swift because of the optimizations Swift wants to do on such types.