Is it practical to load XML map-data AND instantiate objects from this data for “the NEXT room”, while the player shoots monsters in “the CURRENT room”?
Like, is my game just running on one thread by default, and I can just create a new thread to load stuff, so my GAME doesn’t have to wait?
It seems to good to be true, like why should I even need to specify this, if it were THAT easy?
It depends in the complexity of your rooms.
In the general case , yes it’s possible, in fact it is trivial.
However say your game has 8 gig of texture data per room, you are really going to struggle to have two rooms in memory.
So really you have to do some research and work out how big each room is and see if it is even worthwhile thinking about the code
It’s just a 2d metroidvania style map, so rooms are not so huge 
I think what takes time is instantiating objects, because my art is loaded on startup, and takes next to no time at all…
I’m leaning towards “it’s trivial”, at least in theory, but I have NO practice multi-threading, even though I have been programming for years… Any tips on finding relevant info? My searches today are drowning me in a sea of unity and godot tuts, and 3rd party libraries…
Creating a thread and running a task in it is trivial in C#, you can do it in 3 lines of code
ThreadStart childref = new ThreadStart(CallToChildThread);
Thread childThread = new Thread(childref);
childThread.Start();
The difficult bit is making the rest of your code thread safe.
You have to think t through properly.
In your case you would want to create a Room class and put everything your game needs in this.
You have two of them, one the game is using , and one that is being loaded in the background
Only when the loading thread has completed shuld you touch the new room
Otherwise all sorts of nasty things can happen.
This is probably more information than you need, but it illlustrates what I am talking about.
I had a lot of problems on one game that showed up as a crash in a random class when a level is being torn down. The specific symptom was that the “this” pointer was null.
Now there will be people out there right now screaming at their monitors saying “that’s not possible”.
In fact the latest versions of C++ have actually made it illegal to check for a null this pointer as in their tiny minds it is totally impossible.
The problem was I had multiple classes being disposed of that held pointers to other classes that were also being disposed of. The rules said “if you hold a pointer to a class , you must null it when you are disposed”, but lazy coders often forgot. Since they are referenced counted, the pointer hung around even when the object had been disposed, and since this was happening across multiple threads, update could be called on a null object.
The only way I could solve these was to modify the system memory allocator to hold the stack trace when a new object was created so I could look through the memory allocations to find which object was hanging on to a refernce.
As you can imagine this was not fun, slow , painful , and my retribution on the offending coder was biblical.
So think hard before you decide to step into the dark side Luke… errrr Mando…
sounds painful! I’ve never even used a pointer, only heard tales of them 
I have a room class!
You mean create a new instance of room, which is totally inert until completely loaded.
Alright, since my level-class already contains a list of loaded room-instances,
I must now add to that level a “under construction” room-instance. Easy.
…Preventing entry during room construction is easy to imagine. But how does my second thread communicate to the first one when the room is complete? (I mean, just in case, in practice no two doors will be that close)
So when/where do I call that code? Can I put a method for that in my level, and just have it triggered by something in the update loop whenever I see fit?
Alright, it’s cool. I got a seperate thread doing stuff while my character moves around… Then when it’s done it sets a flag that my main thread checks for…
I can work it out from here. Super easy times.