The defaults are included because underlying objects have persistent configuration information stored in the metadata file. If defaults are included in the configuration, we can add new configuration strings without upgrading the metadata file or writing special code in case a configuration string isn't initialized, as long as the new configuration string has an appropriate default value.

Michael, can you please look this over, and then we can talk? (Or if you just love the change, merge it in, it passes the usual tests).

Most of the interesting changes and questions are in conn/conn_btree.c:

1. I quit passing a cfg[] array plus a config string, and instead I'm just passing a created cfg array, and storing that cfg array in the btree handle for the life of the handle. I know you have strong feelings about this, but the way I'm rationalizing the change is that the cfg array represents the total "open state" of the object, so it makes sense to me to do it that way.

Obviously, that's potentially more expensive when digging out configuration values. We could collapse the whole thing, but that seems even more expensive, so I didn't do it.

2. Is this the right place for this change? I chose it because it's where we retrieve the metadata file's configuration, obviously I could push it higher up into the API or lower down into the btree code, but I think the metadata file configuration information would have to tag along for consistency.

3. In *conn_btree_open(), I made a change to not discard the configuration until after *wt_conn_btree_sync_and_close() has returned, that made sense to me, there's no reason sync might not need the configuration?

4. In __wt_conn_btree_discard_single(), I kept the session to btree handle mapping around longer than before, I can't see any reason that's not OK, and it made things simpler.

One change in conn/conn_api.c:wiredtiger_open(): we weren't specifying the key/value formats when creating the metadata file explicitly, I think that was a bug, but I wanted to call it out.