@invisible826 I am not saying it is a duplicate of a Bedrock Edition report. I am just saying that from what I can tell, it appears like the Java Edition bug I mentioned also seems to occur on Bedrock. Also, if you look at the file 'Minecraft 15.08.2023 23_05_26.png', you will see a small portion of a 5-way crossing, and possibly an indent on the same wall, which is what led me to suspect that this is MC-188358.
Looks like this is a duplicate of MC-188358, where strongholds don't always generate indents at the correct locations in 5-way crossings. For example, in this video, the "indents" that indicate "hidden rooms" are supposed to be located where the "hidden rooms" are. This also happens on Bedrock Edition.
This is caused because of code that prevents the walls, floors, and ceilings from replacing air blocks. Jeb originally added this because he "wanted the strongholds to be a little messed up." It does not apply to the stronghold's features and the portal room, which can replace air blocks. Also, it does not apply to a ring of stone bricks that gets generated in place of a room that failed to generate.
Some of the screenshots that were added by Tommy Dendy are from a stronghold with a portal that was overwritten by other parts of the stronghold. The reasoning that @unknown gave when resolving this bug report as "Works as Intended" would apply to this case, but not to cases where the stronghold didn't even generate a portal room. It confuses people by making them think that it is intended that the end portal room is not required to generate in strongholds. An example of a stronghold without a portal room is the seed pollinating sandboxes, at coordinates (74659, -21, -2044).
MCPE-19426 is a bug report on strongholds not generating a portal room and/or stronghold portal rooms being destroyed by other structures and/or overlaps in the stronghold. The description says that the locate command gives a location in which a stronghold is not present when locating strongholds.
This bug is also blocked by the fix for MC-104897, because the game no longer moves the exit portal when respawning the Ender Dragon in old worlds. As a result, it cannot in 1.17 Pre-release 1 or higher. It can still be reproduced in 1.9.
The explanation given in MCPE-19426 by @unknown implies that this is intentional because it explains why it is impractical to prevent the end portal frames from being destroyed, and not why stronghold generation isn't required to generate a portal room.
Even though it was marked "Works as Intended," it was still "fixed" in 1.13. This was caused by the game not generating parts of the stronghold if they would be too close to water, with the exception of the portal room. This could also isolate other parts of the stronghold. 1.13 removed those restrictions on stronghold generation. Even though 1.17 made it so that underwater strongholds are buried below the seabed, the water still does not isolate any rooms.
The name of a country (Japan) and so as the name of their language (Japanese) is affected too.
I found this by looking through the whitelist. I think that this is caused by the anvil showing the popup and undoing the change that caused it to match a word on a file called "profanity_filter.wlist". This could be fixed by displaying the popup and refusing to rename the item when the person tries to take the item out of the anvil rather than as soon as a word on the whitelist is detected in the anvil field. To deal with the words "Night" and "Japan" being banned accidentally, they could add another whitelist.
I don't think I have seen mineshafts overwriting the features of strongholds on Java Edition (at least in modern versions of the game). From what I have seen, the generation mentioned here is caused by code that stops the walls, floors and ceilings (but not the actual features of the room) from replacing air blocks (as in MC-216881). The portal room is the only room that generates fully intact in midair, and it theoretically would overwrite both air and solid blocks of mineshafts based on this assumption.