I say no limits as well.
However, I think I should mention something you may or may not already be aware of. I run Windoze with "virtual memory" turned off so I encountered this more often than most. After only a couple of hours of base editing I would usually get a pop up warning me I'm low on memory before the editor would crash/seize which led me to believe the editor either had a memory leak or the "undo" function was set to log infinitely. If limits are removed, I fear whatever I was encountering could occur even for players with ample "virtual memory".
Sounds like some signals are getting mixed there.
Unless you have far, far too little RAM to even
think about running swapless (and even then it's not a great idea), the COH client by itself can't possibly use enough to exhaust virtual memory. As a 32-bit process on a 64-bit system, it's limited to 4GB address space, max. 2GB if running on a 32-bit OS. In practice, the client will crash if it gets above ~3.7GB.
It's been long known that extended base editor sessions cause the client to slowly grow in memory usage. My gut feeling is a leak somewhere in the process that rebuilds the world from the base map on each edit. Given how complex that process is, it's exponentially more unlikely in a post-shutdown world that it is even possible to fix. The workaround is to periodically exit the editor, and quit to desktop/reload once memory usage starts getting high. This problem isn't something that is unique to bases with a lot of items; it can happen even in simple bases if you edit them long enough.
There is no "undo feature" in the base editor, even though it's something that was asked for repeatedly for a long time.
I've debated about whether or not to keep the 20,000 item hard cap. On one hand, it does serve as a sanity check. Bases with tons and tons of items
will be slower to load and to edit, no way around that. On the other, if people want to build themselves into a corner where the editor becomes unstable and unusable, shouldn't we let them? Or is it better to prevent the heartache by not letting it get that far?
It's not really a griefable situation, since it takes far fewer resources to zone into a base than it does to create that base in the editor to begin with.
Question though: since the 'porters are non functional would it be reasonably possible to somehow implement a menu of destinations that could drop down when you click on the base entry 'porter? Instead of just porting oneself back to the zone he/she/it came from?
Right now the entry portal does nothing, it's not implemented yet. When finished it'll go back to where you came in from, similar to the live behavior. There isn't really a reason to attach a menu to it, since that functionality is already available with /mapmenu.