Hi, patch author here. Two of the falcon patches address the same two issues as my patch series. One caches the expanded $LOAD_PATH (which is expensive to compute mainly because it involves allocating a lot, typically hundreds of KB, and the Ruby GC isn't very efficient), which my patch #4 does. Another speeds up searching the $LOADED_FEATURES array -- his patch keeps it sorted, while my #3 leaves the array unchanged but maintains a hash table pointing into it.
The main difference between the patches is how we maintain the needed invariants, as both $LOAD_PATH and $LOADED_FEATURES are visible to Ruby code and actually mutable from Ruby code. The falcon patches put singleton methods on each of those arrays, wrapping the methods that mutate arrays in order to make them maintain the invariant. This is a very general approach that could implement any desired behavior, but it is relatively complex in the number of cases it has to explicitly handle.
My patches instead take advantage of a feature of the Array implementation to keep a snapshot of each of $LOAD_PATH and $LOADED_FEATURES, and on each 'require' call detect whether they've been mutated. If they have, we rebuild our invariants. This has an advantage in simplicity -- the Array implementation already must track when an Array is mutated, and we just piggyback on that. It can cost more time, but never much more than the status quo (where we must effectively rebuild all the state on every 'require' call), and in normal usage people rarely mutate $LOADED_FEATURES at all and mutate $LOAD_PATH in only one or a handful of bursts, rather than alternating mutation, require, mutation, require many times. So in practice it should be almost as fast as if we never had to rebuild.
NB that funny_falcon himself, aka Yura Sokolov, is participating in the bug thread, so you can read his thoughts there.