This is clearly subjective as I find the newer version far easier to understand. Let me explain:

The first thing that bugged me about this was that `extract_filters_from(*all_configs)` delegates to an iterator over `all_configs`, the result of which we then `inject` over (another iterator). So these two bits were operating at different levels of abstraction, unnecessarily, IMO. The first refactoring I did looked something like this:

```ruby
@options = all_configs.
  each {|c| extract_filters_from(c)}.
  inject ....
```

Next, though the names may _seem_ intention revealing, they're easily misleading. And _I named them_! `extract_filters_from` sounds to me like it it's got a collection of stuff and it returns the filters in the stuff, when in fact it removes them from the stuff and returns everything else. `all_configs` is confusing because elsewhere in the file `config` means a `Configuration` instance, but the `all_configs` method wraps things named `xxx_options`. The new version is explicit about what we're iterating over - it's all right there. I don't have to wonder what `extract_xxx` or `remove_xxx`, etc, might mean.

As for seeing this as one long chain, I see it as a series of steps that each tell a clear story, with the exception of the last step which didn't really change from the old version except that I replaced the `MERGED_OPTIONS` constant with an `Array` literal. `MERGED_OPTIONS`, btw, was confusing to me because just above the reference you see `merged.merge`, which made my head explode :)

Does any of this make sense to you?