I think there should be some kind of feedback then (e.g. a warning) instead of silently ignoring any line breaks, but maybe that's out of scope here.

I'm not sure I'm too comfortable with ignoring the linebreaks either. If it's for consistency, maybe the change should happen in the opposite direction (fix linebreaks where they're already broken instead of the other way around).

At the very least, this should be reflected in tests.

I agree ignoring linebreaks isn't great (though it seems a little cursed to have a linebreak inside an element in a mat/vec).

Vectors probably shouldn't be using the stack function to be layouted anyway (?). I think we should change vectors to use the same layout method as matrices, which would resolve #5422. I'll have a look at why the linebreaks are being ignored in matrices. Adding these changes to this PR is maybe a bit out of scope though.

Ah, I just realised the linebreaks are probably ignored because there would otherwise be issues with alignment points. We wouldn't be able to differentiate alignment points for the whole matrix from ones for the specific element. Maybe, as @EpicEricEE suggested, a warning would be best?

EDIT: Also, the fact that the linebreak works as it does in vec isn't exactly great either. Currently, each line in an element of the vec becomes its own element in the vec when it goes through stack.

The same happens for cases and I think some people write cases(a \ b \ c) rather than using commas. Not saying it's necessarily great, but I'm uncomfortable with merging this as-is, without unifying vec & mat first and potentially displaying some warnings.

I've updated this PR to keep the current behaviour and added tests reflecting the current situation for cases, matrices, and vectors. The linked issue has still been fixed, and this is now the only (user-facing) change made by this PR.

I'll address the inconsistency between vectors (and cases) and matrices with regards to linebreaks when unifying vectors and matrices.

Thanks!