§n does not underline text

Affects 1.11.0.4 beta version

Affects 1.11.0.5 beta version

Affects 1.10 full release

Affects 1.11.0.8 beta version

Affects 1.12.0.2 beta version

Affects 1.11 full release

Affects 1.16.20 Betas (1.16.20.50 & 52), 1.16 Full Release, and 1.16.1.

Affects 1.16.10

Affects 1.16.20

also affects strikethrouke

Still happening in the latest beta (1.16.220.50)

Also in beta 1.17.10.20

Affects 1.17.11

Affects 1.18.12 version

Affects 1.18.30 version

Affects 1.19.10 version
 

Affects 1.19.20

Both still do not work in 1.19.30

Affects 1.19.31 (both §n and §m)

affects 1.19.40, 1.19.50.21 and 1.19.50.22

Affects 1.19.41 and 1.19.50.23

According to wiki, §m and §n are going to be used as color codes in 1.19.80. If this is really released this will break parity
https://minecraft.fandom.com/wiki/Formatting_codes#Color_codes

Affects 1.19.80.22. Would like to mention (tested this in game) that §m and §n are now being used for redstone and copper for the new armor trims, so there may be issues there. Would it be appropriate to create a bug report on it if there isn't one already, because that could be huge for parity.

This report is about the §n and (maybe) §m codes not causing the expected text effects on signs. What your comment is referring to is not about signs or effects. It therefore does not belong in this report. 

I would also point out that what's published on the wiki is original research. It's not official in itself and it doesn't cite official sources. Mojang doesn't document the contents or meaning of network messages between the client and server, so that information is not eligible for reports of parity flaws. Furthermore, even if it were eligible, you cannot report a bug that you only anticipate but doesn't currently exist. 

This is also not the forum for asking questions about how to use the bug tracker. The Mojira Discord exists for that purpose. Please familiarize yourself with our Guidelines and FAQ if you're unclear about what the bug tracker is for and how to use it.

Affects 1.19.80.22. The two codes have recently been implemented to be used with the descriptions of the new armor trims (§m for redstone and §n for copper). They work as these colors across the game in the latest preview. Could be a HUGE issue for parity if it makes it to 1.19.80.

All right, I can see now that what the two of you are referring to is remotely relevant to the issue in this report. However, your concern is a separate question because it's obvious that Mojang intends to reassign the §n and §m codes as new color codes, which precludes fixing this issue at all. I'll need to check with Mojang first, but I expect they've already resolved this report internally as Won't Fix* and neglected to tell us. If so, this report will be resolved the same way.

Obviously, that won't address your concern, so let's look at that next. A new bug report might be appropriate or it might not. What exactly is different about the new colors between Bedrock and Java? Have you considered that this is fresh new behavior and maybe hasn't yet been implemented in one or the other? And what makes you think it's Bedrock and not Java that's doing it wrong? I'm suggesting these questions but I don't expect or want you to answer them here, because again this report isn't about the problem you're describing. I'm simply prompting you to consider these questions before submitting a new bug report—if that's even appropriate.

With respect to whether it's appropriate: The reassignment of these codes was almost certainly intended by design, so your complaint is with the design. The bug tracker is only for bugs—that is, errors in how code implements the design. Issues with design are handled as feature requests and are reported on the Feedback site. If you submit one on the bug tracker, it will simply be closed as Invalid with the explanation that it's a feature request, so I would advise you not to waste your time unless you somehow know (and can tell us) what Mojang's intended design is and that 1.19.80.22 Preview doesn't implement it correctly.

* I've always expected that this ticket would eventually be closed as Won't Fix because underline and strikethrough are particularly tricky to implement on multiple platforms with different screen resolutions and different ways of rendering text. It's probable that Mojang kept this report open for a while as they tried to come up with a consistent solution, but ultimately decided it wasn't worth it for the limited use cases. By then its origin on Mojira wasn't salient anymore so they forgot to tell us.

Affects 1.19.80.23 - The color formatting issues that were discussed yesterday still persist.

Update: Mojang tells me that this report is being kept open pending a future solution, so I won't be resolving it after all. However, I don't think the "parity break" you're worrying about will ever be a problem. Let me explain:

Java stopped supporting § formatting codes quite a while ago in favor of using JSON components. You can no longer use § codes in Java (except in a book & quill, by using unsupported tricks and third-party editors). I assume Bedrock is evolving toward the same target, and by the time they implement underline and strikethrough in Bedrock it will be done using JSON. So that means there's no conflict and §n and §m are available for use as color codes prior to the changeover to JSON.

If my analysis is correct, then, parity is already broken in a sense. It was broken when Java stopped using § formatting codes. I say "in a sense" because I don't believe these codes were ever officially described as a feature for players to use: They're just something the Java code sniffers figured out and documented. In any event, §n and §m have never done any formatting in Bedrock before this, so what is there to break?