There is already a precedent for a signed integer operation to produce an implementation-defined value or to trap. It's for integer conversion:

https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf#subsu...

> Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised.

There is no reason that this wording strategy could not be reused for bit shifts.

In general there is no constraint that unspecified or implementation-defined behavior can't be a trap. Without further qualification "unspecified behavior" or "implementation-defined behavior" is still open-ended, and it's up to the surrounding standard text to restrict the behavior further.

https://open-std.org/JTC1/SC22/WG14/www/docs/n3220.pdf#subse...

> behavior, that results from the use of an unspecified value, or other behavior upon which this document provides two or more possibilities and imposes no further requirements on which is chosen in any instance

"Possibilities" include trap