Bloo

Scoreboard entries of actual entities are usually never persistent past the entity's death. The only way for the "user“ to make persistent entries is by using an explicit score holder name in a command.

The fact that a score with the name being the uuid of the – now dead – holder remains clearly breaks this rule. The "user“ never created a score under that name and it can be almost impossible to reference these leftover scores.

I have not tried this in recent versions, we should investigate whether this bug re-appeared. If so, this would need to be re-opened.

Grant Yes, if the game saved all the data from the player head item on the tile entity and properly restored the item to that data when the player head block is broken, we wouldn't need to do any of this.

In that case it would be fine if SkullOwner.Name can only contain real player names.

I'd also like to add some context to make you aware of how widely used the old behavior (SkullOwner.Name can contain any string) is and why it is so widely used; Vanilla Tweaks mentioned in the above issue is not the only use case, it is merly an example.

Another Example

Gamemode 4 also uses that behavior to repair its player heads when placed down (exact link to the mcfunction library responsible).

Why Is This Behavior So Useful to the mcfunction Community?

When a player head is placed down (before snapshot 24w09a) two properties from the player head item are conserved: SkullOwner.Name and SkullOwner.Properties.textures[0].
These are two very special tags to us, as player heads are often used as a form of custom item that has an in-built texture without needing a resource pack, and we don't want those to break when a player places them down, breaks them, and picks them back up!
Hence each player head used as such an item must use one of these two tags and insert a unique value so that once the placed down player head is broken and on ground in item form, commands can restore the rest of its NBT to the default state of that custom item (e.g. lore or just some other NBT data).

So why do we prefer matching a unique value in SkullOwner.Name instead of simply matching the texture? It's because the texture is not necessarily unique! There may be multiple of these custom player heads that share a texture, but are restored to different custom heads (e.g. different lores).
Apart from that, using SkullOwner.name also allows us to put a nice '[Drop to Fix]' in the name, so in case a player picks up the player head before the commands got around to fixing, the player is instructed to drop it again.

Over the years the community has settled on a de-facto standard where we store unique strings, usually even namespaced by our datapacks and with a '[Drop to Fix]' message in front, in the SkullOwner.Name to allow us to restore the skulls when they are placed and subsequently broken. Such a string may look like '[Drop to Fix] gm4_metallurgy:arborenda_shamir'.

As you can see, these strings may be very long (longer than 16 characters for sure!) and use non-ascii characters. As a result, these are definitely not real player names, and they're not meant to be! The fact that SkullOwner.Name can have invalid player names is something we really value a lot.

I hope this could add some much needed context.

In Changelog 1.18.0 ( bedrock ) the "Known Issues" section is written:

New world generation in this release is currently incompatible with the 'Creation of Custom Biomes' experimental toggle. Expect worlds with custom biome generation to be potentially unstable and for custom biomes to only exist in currently saved out areas of the world.

I just tried, but it still doesn't work 😞

This no longer happens in 1.17.1.

Also happens in 1.17.1-pre1.

Thanks Grey, but is it really?

It does not affect all ridden entities. Command Blocks were able to teleport the minecart / the horse whilst I was riding the cart/the horse, however, Command Blocks can not teleport a boat ridden by a player - only the player riding the boat can.

It doesn't work with horses nor does it work with minecarts