I do not think it should be back-ported because there is a work around which is to not duplicate such shipment (which should anywhere never be duplicated).
But I do not find using default is enough reliable to enforce the behavior because call could have already a default value for origin.

Is this considered as a bug or as a feature? Do we plan to backport?
I'm asking because if we do not plan to backport I'm wondering if it's possible to use the callable feature of copy default to avoid the extra call of save and clearing the values directly with the copy call.

The module stock_split allows splitting a stock.move also when it is in assigned state and stock_consignment creates the invoice line in the assigned state, so it is possible that the user splits the move when the invoice line has already been created and removing the origin in this case would probably be wrong.
One option would be to create the invoice line once the move is in "done" state (which I think is a better workflow for the user), though that requires to add a mechanism to prevent the warning that the move has no origin when it's assigned.