Each database driver needs to be able to define their own method of handling configuration storage. For an RDBMS storing a serialized array makes sense, but for a key-value store storing a serialized array would be nonsense.

Well, no matter what storage, its going to be a serialized array. It may be PHP or XML or JSON or whatever, but one way or another you're serializing an array down to a specific format. That's not going to change at this point.

That said, I'm not sure why these changes are necessary for this issue/patch in the first place? We should be able to move the encoding/decoding operations into the storage controllers without the other architectural changes.