But perhaps you meant mainly to suggest FSET as a method for avoiding shared mutable data? There should never be open mutation, even of the closure data. The safety of fully parallel concurrency can only be guaranteed by performing all mutations through BECOME which relies on a CAS operation in the dispatch threads.
I suppose you could get around that restriction with FSET. But then so could you with LOCKS and SEMAPHORES and all the other SMP primitives.
Right now, as long as you abide by functional coding and BECOME as the only mutator, we can completely dispense with LOCKS, THREADS, SEMAPHORES, MAILBOXES. None of that is necessary at the user programmer level. You code as though you are the sole occupant of the machine. And so long as you abide by clean conventions, fully parallel concurrency is yours.
The same code runs as well in a single thread, or on multiple cores and threads. Speed of execution is the only variable.
This is a fairly narrow mode of operation, where a task can functionally produce an output that gets committed with a single atomic operation. Most often, (green or SMP) threads are used when an operation must naturally interleave computation with mutation of shared structures and I/O.