Domolas

No, but similar issue. The bug appeared when the world was updated, even though no datapacks were deleted. My custom dimension was not using the default namespace either.

Update 2: I have determined that the problems are caused by the level.dat file, which were missing the tags for the End and the custom dimension. After adding back the tag for the End using an NBT editor (copying values from the 1.16.5 backup), the End became accessible, but after adding back the tag for the custom dimension (also copying the values from the 1.16.5 backup), both the custom dimension and the End were removed from the level.dat file.

Update: It appears that the inaccessible dimensions in the world are missing an "entities" folder, while the accessible dimensions in the world, as well as dimensions in other 1.17 worlds, have an "entities" folder.

I found a workaround (requires cheats to be on). Type in the command 

/data merge entity _UUID_ {VillagerData:{profession:"minecraft:_PROFESSION_"},Brain:{memories:{"minecraft:job_site":{value:{pos:[I;_X_,_Y_,_Z_],dimension:"minecraft:_DIMENSION_"}}}}}

where UUID is the UUID of the villager, PROFESSION is the intended profession of the villager, X, Y, and Z are the coordinates of the intended job site, and DIMENSION is the dimension in which the intended job site is in.

No, they did not

I created the maps with this tool.

Does changing the render distance affect this?

My results for this: https://www.youtube.com/watch?v=V2uDIv2n260

A few minutes later, I tried it again, at a different location on the same world, and both command blocks worked! The detector rail is at (1293, 71, -739), the command block executing when the detector rail is powered is at (1288, 71, -743), and the command block executing when the detector rail is not powered is at (1288, 71, -741). Is the bug linked to the location of the command blocks?