• In 1.16.3, 1.16.5, and 21w08b : If a region file is copied from one world to another, and if the region file's name is unchanged, it seems to copy correctly. However, if the name of the region file is changed (i.e. from r.-5.-5.mca to r.0.0.mca) all chests and double chests are missing. This applies to both naturally generated chests and chests placed by any player.
• In 1.16.3 and 1.16.5 the only way to make the missing chests appear is by entering spectator mode and flying into them. That causes them to appear, which suggests the data is still there somewhere, but when the chests are then opened in survival mode they are all empty.
• In snapshot 21w08b entering spectator mode will NOT cause the chest to appear.
• In 1.16.3 and 1.16.5 and 21w08b Shulker boxes do NOT disappear when the region file is renamed, however, they are all empty. Villagers also disappear and Illager spawns no longer occur.

These issues are caused by the fact that various blocks use absolute coordinates rather than relative coordinates. When the region file name is changed the coordinate of the blocks are also changed.

This causes some data entries to read as INVALID which can prevent spawns. For example, when a naturally generated village reads as id:INVALID it's villagers vanish (which is especially strange since the players can make their own villages so that shouldn't matter). When a naturally generated forest mansion reads as id:INVALID the Illagers also vanish (so no more Evokers).

With other objects, such as shulker boxes, the ID doesn't change to INVALID like chests do, so they spawn as normal, but their contents end up missing because the absolute coordinates are still stored.

For example, in one of my tests I changed a region file from r.-5.-5 to r.0.0 as part of a world merge and the shulker box was empty in the new world. This is what it was read as:

id: minecraft:shulker_box
x: -2288
y: 72
z: -2248

So, since the absolute coordinates are not possible for the current region, the contents of the chest are never made available.

Note that while this does not occur if the region file name is not changed, thus meaning that people who are simply backing up region files are safe, for those who may want to import a piece of an old server into a new world with new generation this could present major problems. For a project that I am working on it's definitely been causing issues.

There is a simple solution to this bug though:

When an absolute coordinate is read which is impossible for the current region the game can run a simple calculation to determine what the coordinate should be and update it on the fly using the following equations:

Relative Coordinate = absolute coordinate % 512 // that's a Modulo operation
((region coordinate) * 512) + relative coordinate = coordinate at region.

So, using the above example, where r.-5.-5.mca was now located in another region - let's say it's now in r.1.-3.mca :

X:

((1) * 512) + (-2288 % 512) = 784

Z:

((-3) * 512) + (-2248 % 512) = -752

Therefore, in this case, the game knows that what reads as (-2288 72 -2248) should be changed to (784 72 -752) and then if it does so on the fly, when the error is detected INSTEAD of marking blocks as invalid and/or leaving them orphaned the entire bug would be resolved. The game wouldn't need to change how region files are put together, nor would it need to store the original region name anywhere. All it would need to do is - whenever an INVALID coordinate is detected - run the above equations and update the coordinates with the results to make them valid. That should be simple enough to do.

This would be an extremely simple fix to make, making use of existing checks for valid coordinates (although expanding those checks to include chests) which would totally solve the problem and make world mergers possible without risk of world corruption. I understand that this is outside normal single player gameplay, but old worlds are occasionally merged and this type of behavior is therefore a bug that results from predictable user action.