mrpingouin1

Here is a repo from last year advent of code : oac2021
90% of the solutions are obsolete now because it often involves inputs of around 10k characters. Input are not included in the repo because they are automatically generated, but here is how one input would look like : gist

In the pre-3, that command fail.

I cannot test the impact on speed because size is the main issue there.

Can confirm for 22w19a, this is also the same as MC-170764

It's still an issue in 1.17.1. The mentioned bug don't seem to be exactly related.
Adding items does fix the issue, but you might want to test regardless of the exact item id, and adding the following part still does cause the same issue :

"items": [
          "minecraft:golden_sword","minecraft:air"
        ]

Duplicates of MC-92282. You should put the command you are using, but you mostly likely did not specify a correct SpawnPotentials tag.

@ is not a valid selector so it won't target any players

I think it's just the 

/tag @e remove TagMe

that just notify you that you tried to remove the TagMe from all entities since you used @e. Using either of these commands before the remove shouldn't list all entities :

/tag @e[tag=TagMe] remove TagMe
/say @e[tag=TagMe]

You can find more of these issues with most "optional" tags. So even if it would be convenient to have some of these fixed, in the general case, I think it falls under the "changing the nbt in the block/entity lifetime" category.

Probably WAI, but it could change if there are too much issue with the RootVehicle implementation.

RootVehicle was made so that when a player disconnect, the entity the player is riding also despawn. I fail to see how this could work well if both players had a RootVehicle compound of the same boat.
This imply the sad truth that with RootVehicle, you can't detect things correctly when 2 players are on the same boat.

So you expect the syntax parser to tell you that the following is invalid :

{ikjuh:rf}

But it's a valid nbt, its syntax is valid. Sure the armor_stand doesn't have such NBT, but the syntax parser doesn't really know that.
Also you don't really need to learn nbt, you can either use the wiki to have the full list, or you could just use /data get entity @e[type=armor_stand,count=1,sort=nearest]

This has nothing to do with the nbt selector argument. On your first command, you have execute as @e[nbt=...], and on the other command, just @s (so basically nothing). No wonder why one is wait faster than the other. With as @e[nbt=...], you loop through every entity in the world and test their nbt, so really you can't compare both cases.

If you want to point out potential optimizations issues, try to use two very similar commands, in the same controlled environment (like in MC-124072)

Confirmed.
When a villager convert to a zombie and back to a villager, only the Profession is keept.
The career is picked randomly when the player interact with the new villager for the first time, so technically, a freshly converted villager is neither a cartographer nor a librarian.

Disambiguation : a Villager with Librarian Profession has two possible Career : Librarian and Cartographer (see wiki).

Duplicate of MC-122726

Confirmed, each of the Head, Body, LeftArm, RightArm, LeftLeg, RightLeg tag in Pose are not saved to nbt when they have their default position (It's not necesseraly [0,0,0] for arm and legs).
It looks intentionnal to not save extra data when there is no need to, but we didn't have /data get back then.

To avoid that issue, you can use a value very close to the default one, like this :

{Pose:{Head:[0.0f,0.0f,1e-9f]}}

Duplicates of MC-121278, caused by non QWERTY keyboard

Confirmed even more by digging a bit :
This is caused by the method glfwSetKeyCallback who returns a key code assuming a US keyboard layout.
To fix it, instead of directly testing the key code returned by glfwSetKeyCallback with the GLFW_KEY constants, it has to be converted to his printable character with the glfwGetKeyName method.

Just to be sure, do you rather mean CTRL+A in the title?
Otherwise I can also confirm that using CTRL+A to select text isn't working, and I have to use CTRL+Q instead.
The F3+A and F3+Q shorcuts are also affected and thefore swapped out.

It seems to be caused by the use of an azerty keyboard in my case

Cannot reproduce, the CanPickUpLoot stay at 1b when I tame it with a bone.

Confirmed
Based on mcp940-pre1, minecraft version 1.12, the method EntityAINearestAttackableTarget.getTargetableArea is defined as follow :

//targetDistance is the follow range
    protected AxisAlignedBB getTargetableArea(double targetDistance)
    {
        return this.taskOwner.getEntityBoundingBox().expand(targetDistance, 4.0D, targetDistance);
    }

And indeed the BoundingBox y expansion is always a constant 4.0, regardless of the follow range.

About why it relates to MC-102348 :
One of the cause is that villagers can schedule village door check that occur right between the chunk unload and entities update.
As said in the comments of MC-96131, any use of World.getBlockState can be a cause of chunk reload in the same tick, so this issue could be caused but other things beside door check and commands.

Duplicate of MC-87296