No, you are not wrong. Nothing has changed at all. The opposite is the case, FlightGear's multithreading use is more likely to complicate a "distributed setup" (running a modular FG on multiple different computers) like the one you describe.
And this setup is in fact exactly the way professional simulators work, too: They are distributed and communicate using sockets. Mathias' ongoing HLA work is going to make that increasingly feasible however.
OSG threading is neat and dandy, but obviously it is only directly useful for rendering related parallelization and related work. On the other hand, none of this comes for free. OSG's threading support really is impressive, but all those OSG threads must be kept busy. Properly. That's exactly the work that FlightGear is responsible for in its main loop.
OSG's multithreading support doesn't just come "automagically", just because FlightGear uses OSG.
The multithreading support in OSG must be explicitly supported by following certain OSG coding patterns and coding protocols. Otherwise, you won't benefit at all.
Obviously, OSG really is extremely powerful and also pretty good at parallelizing things, but you cannot necessarily see that when running FlightGear, but there is other OSG-based software which is making really good use of this.
Regarding Curt's comments, you have to take his background in mind ...
Curt isn't just the head of FlightGear development, but he's also the head of the "
anti-multithreading movement", too
Seriously, Curt has been giving soapbox speeches on avoiding multithreading in FlightGear for over a decade. So he is obviously happy to point out that there's plenty of parallelism to be leveraged just by using OSG rather than supporting explicit parallelism in FlightGear, right?
You can find countless discussions on multithreading FG in the devel archives, and Curt's always been suggesting not to introduce more threading into FlightGear.
He did that for good reasons: correct multithreading is incredibly hard to get right in any non-trivial application.
Especially in complex systems like FlightGear. This holds even more true because FlightGear is implemented in C and C++, none of which has language-level support for concurrency and parallelism.
Basically, there's no language-level support for multithreading in the C-family of languages. Everything needs to be built and emulated using library-functions and classes such as Boost (this is less so in Java).
Still, coding a threaded design in C or C++ with more than 3-5 threads is incredibly tricky to get right (this will also be a problem once more threading will be used in Nasal code, because it also lacks language-level threading support).
There are languages far better suited for multithreaded programming, such as Ada - because they have language-level primitives to create "tasks" and "protected types".
However, what's really been happening in the meantime is that people were politely (more or less) debating the pros & cons of multithreading on the devel list, while silently committing multithreaded code to SimGear and FlightGear...to keep up with the multicore revolution.
Unfortunately, half a decade later, Curt's getting proven right because we are seeing more and more segfaults related to this very multithreaded code in FG. Just look at all the bugs that ThorstenB tracked down recently, most of them are directly related to concurrency issues and multiple threads doing things in a fashion which isn't threadsafe.
Mathias' HLA approach is different and more promising in that a process-based parallelization effort actually
forces people to think about the problem at hand. Also, using an existing industry standard (such as i.e. HLA or CIGI) is going to make FlightGear increasingly relevant and attractive to industry leaders.
Normally, a process-based modularization strategy would inevitably mean that modules need to be run as separate processes, but Mathias mentioned a clever scheme to directly run certain "component subsystems" in worker threads, which would then be a part of the main FG process, while still using HLA and a central RTI to handle the communications across all HLA federates.
Seriously though, I would suggest to take everything you can read here with a grain of salt.
The wiki is full with tons of outdated "suggestions" and "proposals", many of them should only be kept for reference because they do point to important mailing lits discussions, but apart from that, they're of little use in my opinion actually.
The only person who really knows more about this is obviously Mathias because he is intimately familiar with OSG and HLA.
So, what I have posted were quotes coming "from the horse's mouth".
Honestly, I am pretty convinced that Mathias HLA work is at least as important and pioneering as David Megginson's original property tree work.
FlightGear will become much more scalable, and much more so than MSFS or X-Plane.
Also, it's obvious that more and more companies are going to be interested in FlightGear once such an architecture is implemented.