I think he's talking about the unique tile limit for DMMs.

The DMM index limit is 65,535 unique tile indices per map. This is different form the compile-time object limit.

You are just going to have to do dynamic area loading/unloading, or break your game into multiple servers.

I'm not clear on which limit you're referring to.

There are several limits still built into the .dmb file itself that are stuck on 64K, whereas at runtime most things can now be expanded well beyond that. It sounds to me like the limit you're seeing is a limited number of map pops. A "pop" is a special ID that goes along with each unique map tile, and is used to repopulate the map during Repop(). Map pops are most definitely limited to 64K.

Unique type paths are also limited. Some authors go bonkers with this.

There are other limits but I don't think they apply. For instance, when turfs are stacked you still only have one turf, but the others go into the underlays list. Unique underlays lists are limited, but I don't think you can hit the compile-time 64K restriction (runtime is much higher) without running into the pop limit.

For the time being, your best way to deal with the pop limit is to do some editing to trim your map files down. You may have a number of pops that are identical except for one or two things that don't even matter; if you can eliminate those differences and collapse five or six pops down to one, you'll save all those duplicate IDs for where they're really needed. The pop limit is a hard one to hit.

If you're doing something like pixel offsets on a number of meaningless decor items, that would be one place you could save a lot. One option you have for saving space is adding something to New() that sets the pixel offsets based on a hash of the item's position, which can give the appearance of randomness.