I don't have a routine for rendering yet, so it could be done using two containers or perhaps while avoiding a for loop. What I am trying to say is that the render routine can be designed as efficiently as possible after committing to how I store the tile map as a whole.
Not quite. The way your store your data directly affects how quickly you can access that data. Storing an fire extinguisher inside a locked closet makes it less accessible during an emergency than mounting it on a wall. You can optimize your "fire emergency procedures" as fast as you like, but until you change where it is stored, your "best time" will be determined purely by the closet and the lock.
Since your data storage determines the minimum access time, designing your routines "as efficiently as possible" *after* "committing" to a slow data storage, means you can only optimize up to your data's already slow layout.
I could have a container for the tile map in its entirety, and yet another for what will be rendered which then could in turn be updated as efficiently as possible.
If you think about this sentence you just said, there's an important insight here.
To highly paraphrase your sentence, you just said: "I could store more data, and do more work, and optimize that extra work as efficiently as possible"
You know what the most "as efficiently as possible" solution is for doing more unnecessary work? Not doing the unnecessary work at all.
Doing nothing is always faster than doing something, so if that 'something' isn't necessary, it's faster to not need to do it in the first place.
This is not premature optimization. This is knowing your needs in advance, and designing your architecture for that. Your needs, which you'll find out eventually, is iteration speed and access speed. std::vectors trump std::maps in both of those areas. What maps win at are searches; and even then, they only win at searches when you got large amounts of data.
Moving onto the second part regarding how you would go about this using chunks of (tiles wide x tiles high). I guess there is one more specification I didn't consider. Everything is sized differently. Even rooms that would share the same visual space can be different sizes. When you leave Room A and enter Room B only half of Room A might be replaced.
So how would you design chunks around that little caveat?
You don't need to.
If your world is a seamlessly scrolling world, your areas don't need to line up to chunks. A room might horizontally use 2 and 7/9ths of a chunk - it doesn't matter; chunks don't know about rooms, rooms don't know about chunks. "Chunks" are just collections of tiles. "Rooms" are just pictures draw using those tiles.
This scene (WIP pic from my game from ~2010), shows two things that could be described as "rooms" (depending on how you want to count the hallways). It's split across more than one chunk. Chunks don't affect gameplay, they just silently existing for streaming data in and out as the player moves around.
I don't remember exactly where the chunks fell - the chunks are supposed to be invisible grouping of tiles, not observable by the player, or even the person designing the maps (though they can see it if they want, it shouldn't affect the map design). It's a behind the scenes optimization to make everything work smoothly and seamlessly.
The chunk divisions could've easily fallen like this, without any difference to the gameplay or visuals:
Here's another shot (from a few days ago), showing how even objects can straddle the chunks. The chunk boundaries are seamless and invisible to entities within the world.
(the chunk lines in this screenshot aren't guesses: the editor is drawing them)
I don't know your gameplay needs, so maybe you have some special gameplay related to the concept of rooms (as opposed to mere visuals and collisions)? If so, chunks still don't need to know about rooms, nor rooms about chunks. Just use rectangles (or collections of rectangles) to define the areas of your rooms on top of, over, and without knowledge of, the chunks.