Has to do with differences between vanilla/forge and bukkit.
From GT_API_Proxy:
@SubscribeEvent(priority = EventPriority.LOWEST) public void onWorldSave (WorldEvent.Save aEvent) {checkSaveLocation(aEvent.world.getSaveHandler().getWorldDirectory(), F);}
(Plus other events that call checkSaveLocation)
On forge that getSaveHandler().getWorldDirectory() gives you the base path of your world (i.e. ./greg6-world, while it gives you the ‘level’ path for bukkit (i.e. ./greg6-world/DIM-1 if the event is from that ‘level’ (that is, dimension), vs ./greg6-world which you only get for DIM0 in bukkit).
It works that way in bukkit due to historic reasons, and bukkit/forge hybrids keep it for compatability I assume. Or perhaps it has never been a problem since few mods seem to care about the actual save location.
GT_API_Proxy#checkSaveLocation() compares the passed in File location with a stored one, and it will think the world has been changed if they differ (which they will since you get one for each dimension and they never match.
GT_API_Proxy#onWorldTick() also uses checkSaveLocation() to handle TileEntities that do care about worlds, like miniature portals. If they think the world has changed they will invalidate the per-world list of active portals, and this will happen like every second so portals never get a chance to connect…
(plus it will spam your gregtech.log with “Loading world!”/“Saving world!” every second, filling that up…)