Vfork in most older systems is like fork except it doesn't deeply duplicate all process state immediately (file handles, memory, such), so it can be faster if all the app wants to do is fork/exec. (We had to implement both fork and vfork in minix 2.x in uni.^)
But according to SO, most OSes implement fork lazily, so there's not much point in using it when fork will be just as fast without any change.
If there were a slowly-performing platform that has a specific performance issue identified by profiling as caused by fork, then mature optimization could follow. Otherwise, it seems like adding LoC without a clear goal.
The Symbol GC sounds good. Maybe this will imply code can associated with classes and modules can be GCed and required anew once all objects are freed (live upgrade apps without restarts).
^ The first thing I did to the Minix codebase was set keyboard repeat rate to the fastest possible values. Everyone else seemed content to waste their life waiting for their editor and debugger to move at a snail's pace. Of course, no else had x86 asm / pc hw io experience.
For example, 'FooBarWidget @ Passenger 5 "Raptor" is a well-crafted, thoughtful achievement in terms of app servers.
2.2 Symbol GC also sounds great. I'm just not convinced there is enough innovation to make Ruby an order-of-magnitude faster, use less memory / return memory back to the system.