I might use separate layouts if it weren't for the runtime error that occurs everytime I either:
Go to a different layout.
Restart the same layout.
Load a game save.
Are you using transitions? If I recall correctly, those can cause crashes. The 'or' condition can cause crashes as well.
If you want to find out what's causing them, save a copy of your .cap then start deleting chunks of code to find out what causes it.
I have been working on a different game and made a very large map, a size in the tens of thousands, and neither Construct nor the app so much as coughed about it. I heard layers were rendered as textures so it didn't make sense to me that it could handle images that large unless it were culling things off screen. Mind you this layout had several layers with various graphics and objects spanning the size of the map, the level layouts, decorations, background layers, game objects, etc.
Tens of thousands is no problem. Layers are only rendered as textures if you set them that way in the layer properties. Even then, it's only the part of the layer that's visible on screen. Stuff that's off screen isn't rendered, the graphics card takes care of that automatically, but the logic of the objects is still there and being processed.
Loading only parts of the map when the player is near is a good idea too, but how do I do that? Do you mean loading external images in place of sprites? I tried that too and it was picky about what images were loaded. Some images worked and others gave me the same runtime error that changing layouts gave me.
Don't load external images unless you're willing to put up with a delay while the hard drive reads the file, stores at memory and then flings it to the graphics card. That can take long enough to be noticeable. Best to load from files during transitions between areas.
You would want them to be preexisting objects that you create and destroy based upon the proximity of the player. You could divide all of the objects into a sections on a grid, save all of the instances in each grid cell to an array, and when you get close to the boundary of one section, you could create all the instances in the new section, and when far enough away from the old one, delete them. This isn't really a simple thing though.