Capopanzone

Paths and farmland are fine, they are affected by ambient occlusion (their sides are darkened towards the bottom). They don't cast a shadow, which is a separate issue that affects other partial blocks as well (slabs, stairs etc) - MC-139621

The new look of the pipe symbol is correct, as it's a pipe and not a broken bar (¦ U+00A6). Adding spaces or color-coding the command suggestions would be the ideal fixes

Can confirm

Can confirm

It seems to be fixed, it didn't seem to be an issue in 39a either (except at biome borders)

A bunch of extreme hills sub-biomes were missed in the experimental snapshots and weren't renamed. I imagine we should report them separately if they don't get renamed along with the other extreme hills in the next snapshots, but I'll report them here for now, in case Mojang reads these comments.

• wooded_mountains -> wooded_hills

  • Currently, wooded_hills is the name of the now-unused hill variant of forests. The current wooded_hills should be renamed to forest_hills

• mountain_edge -> extreme_hill_edge

  • Unused biome, but it should be renamed for consistency. Despite being unused, it was already renamed back in 1.13 pre-release 5 along with the other extreme hills biomes.

• modified_gravelly_mountains -> modified_gravelly_hills

  • Now-unused biome, but it should be renamed for consistency.

• taiga_mountains -> extreme_taiga_hills

  • Now-unused modified variant of taiga, and unrelated to extreme hills, but it should probably be renamed to avoid people getting confused when using /locatebiome (same reason for the mountains -> extreme_hills rename)

The generation of ground vegetation seems a bit off in general, probably due to 3D biomes.

Fixed in 1.17.30.22 by adding separate strings for awkward/thick/mundane potions, and all types of splash and lingering potions.

still an issue in the most recent versions

I've dug into the Minecraft code (version 1.17.1-pre1, decompiled using Mojang's mappings) and found the cause. I've come up with a possible fix, but I'm not entirely sure it will work, as I've had no way to test it and my Java knowledge is extremely limited and extremely rusty.

Code analysis

com.mojang.brigadier.exceptions.CommandSyntaxtExceptions.java

The getContext method returns the last 10 characters of a faulty inputted command, followed by "<--[HERE]-". "<-[HERE]-" is defined directly in the code, so it's not translatable. This is intended, Brigadier is meant to be a standalone library which can be used by other pieces of software, so it should not directly reference any Minecraft classes or assets. However, this is the reason why "<-[HERE]" is not translatable in the parse error message.

public String getContext() {
        if (this.input == null || this.cursor < 0) {
            return null;
        }
        StringBuilder stringBuilder = new StringBuilder();
        int n = Math.min(this.input.length(), this.cursor);
        if (n > 10) {
            stringBuilder.append("...");
        }
        stringBuilder.append(this.input.substring(Math.max(0, n - 10), n));
        stringBuilder.append("<--[HERE]");
        return stringBuilder.toString();
    }

net.minecraft.client.gui.components.CommandSuggestions.java

The getExceptionMessage method prepares the parse error message by inputting the cursor position and the command context in the translation string command.context.parse_error ("in position %s: %s"). The command context is returned by the getContext method from the Brigadier library, so it includes the hardcoded "<--[HERE]".

private static FormattedCharSequence getExceptionMessage(CommandSyntaxException commandSyntaxException) {
        Component component = ComponentUtils.fromMessage(commandSyntaxException.getRawMessage());
        String string = commandSyntaxException.getContext();
        if (string == null) {
            return component.getVisualOrderText();
        }
        return new TranslatableComponent("command.context.parse_error", component, commandSyntaxException.getCursor(), string).getVisualOrderText();
    }

Possible fix

com.mojang.brigadier.exceptions.CommandSyntaxtExceptions.java

I suggest fixing it by adding a new method which only returns the last 10 characters of the input command, whithout appending anything after it. The game will use this method - instead of getContext - to prepare the parse error message.

public String getRawContext() {
        if (this.input == null || this.cursor < 0) {
            return null;
        }
        StringBuilder stringBuilder = new StringBuilder();
        int n = Math.min(this.input.length(), this.cursor);
        if (n > 10) {
            stringBuilder.append("...");
        }
        stringBuilder.append(this.input.substring(Math.max(0, n - 10), n));
        return stringBuilder.toString();
    }

getContext now will simply append "<--[HERE]" to the output of getRawContext.

public String getContext() {
		StringBuilder stringBuilder = newStringBuilder(this.getRawContext());
		stringBuilder.append("<--[HERE]");
		return stringBuilder.toString()
	}

net.minecraft.client.gui.components.CommandSuggestions.java

getExceptionMessage will now reference getRawContext instead of getContext.

private static FormattedCharSequence getExceptionMessage(CommandSyntaxException commandSyntaxException) {
        Component component = ComponentUtils.fromMessage(commandSyntaxException.getRawMessage());
        String string = commandSyntaxException.getRawContext();
        if (string == null) {
            return component.getVisualOrderText();
        }
        return new TranslatableComponent("command.context.parse_error", component, commandSyntaxException.getCursor(), string).getVisualOrderText();
    }

en_us.json

The string command.context.parse_error should then be changed to include "<--[HERE]", allowing translators to translate it properly and change the word order if needed.

"command.context.parse_error": "in position %s: %s<--[HERE]",

MC-129428 is still open and was triaged by Mojang, and MC-173015 was fixed. Saplings and mushrooms are growable plants, while dead bushes are simplier ground cover blocks, more similar to flowers and grass.

Also affects potted azaleas and potted flowering azaleas

This is also a parity issue, as in Bedrock axolotl buckets have different names depending on the axolotl variant (for example: "Bucket of Adult Cyan Axolotl", "Bucket of Baby Leucistic Axolotl")

The simpliest fix would be allowing grass and flowers to be placed on sand and gravel (MC-223826). In real life you can find some plants can grow on sandy and gravelly soils, and in Minecraft it would allow for more decoration options.

can confirm

Here's an alternative fix with no weird mirroring effects at some angles

.

Can confirm

Related issue with names: MC-213911

Still an issue in 21w05a

It might have been fixed for copper blocks (as their names got shortened), but 35 characters is still too low for other names in other languages, so the core issue here (anvil char limit being too low) hasn't been fixed yet.