Huh, no clue what you're talking about. You listed 4 out of 5 parameter-problem codes (i.e. 4/0, 4/1, 4/1 and 4/3), so I noted you missed 4/4 too. Are you trying to add more types of ICMPv6 types other than parameter-problem?
I just took type 4 as a sample for getting feedback on a coalesced syntax since I thought that might be better than working with abstracts, but not really to debate the merits of particular type/code settings in the fw.
since there is no code 123. That is I am wondering whether such coalesced syntax is correct and the issue is in LuCI not exhibiting the code 0 or whether the syntax is just sort of bogus - but then I would have expected fw to throw an error which is does not however.
Although, this does appear in the firewall as 123. I'm certain a multi-digit code beginning with a 0 is not standard (looking at the IANA site) - so 0123 is interpreted as 123. Also typing 0123 doesn't (by syntax) specify codes 0 thru 3.
Additionally, you noted, there's no code 0123, but (from experience) I'm not surprised that undefined types are applying instead of throwing errors. Otherwise all routers and firewalls must be immediately upgraded if new ICMP types are formally defined, even temporary ones for reserved and testing. See the IANA page where many ICMP types have ranges of undefined codes.
I'm not sure why you're trying to put all code-types in one line. Is that your specific request or do you have a reason to believe this one-line syntax should work?
Is there an issue making a line for each type in the same rule?
Otherwise, I advice you create ICMPv6 rules as @shm0 noted: