There's been enough people trying to use multiple kOS parts in conjunction as a sort of multi-threaded approach that I guess it's time to try to support at least some sort of crude model that will allow that. The key things that cannot be done by user-level code alone and need kOS support are:

1. Some way to share memory between cores on the same vessel. This would be a way for one core to set a variable that another core can read. One possible way is to use the current ship message queue, but it would be nice if they could just share variables more directly with, say, one universal variable dictionary that all kOS parts can see (a sort of "even more global than global" namespace.) One possible way to do this with minimal effort would be to just provide a single lexicon everyone can see, like if one core does set ship:sharedlex["foo"] to 5. then another core can do print ship:sharedlex["foo"]. (Intuitively that might seem like a slow way to access memory, but in kOS even the "direct" variables are still dictionary lookups in the C# under the hood so that doesn't really matter too much. A program could just first do set sharedFoo to ship:sharedlex["foo"]. up front, then refer to sharedFoo from then on, if the author is concerned about speed of accessing the variable.)
2. Some way for a script to have "atomic access" to a semaphore or mutex, so that when the script's algorithm requires it, it can declare atomic sections where the other cores requesting the same "baton" have to wait their turn. Please note, this would NOT be an "atomic section" from the point of view of KSP itself. This kind of "atomic section" could still run out of IPU and have to continue next physics update. But what this would do is make it so that if a core that "has the baton" runs past its IPU and has to continue next physics update, the other kOS cores that requested access to the same "baton" won't wake up and run their opcodes until that "baton" is freed by this one. I envision something like this: Currently each physics update, a core wakes up and runs IPU opcodes. The change would be that a core wakes up, checks to see if it's requesting a baton that's in use, and only if that baton is not in use will it proceed to execute the next IPU worth of opcodes, otherwise it will to go back to sleep and try again next update. Obviously, there will need to be failsafes to make sure "the baton" gets freed when a program dies or a the core part explodes.

Documentation: This could be the messiest part. I wish to keep kOS well documented, and like it's sort of friendly "not too complex for the newbie" approach, but this topic is not one to just "gloss over" quickly. It may be impossible to document how one would use these features without it being well above the newbie level. It may be that the documentation will just have to point to some wikipedia articles, point out "this is a very advanced topic beyond the scope of this documentation", and then just describe how the features can be used by the people who already understand it.