There are certain things that _might_ benefit from the third kind we currently do not support: developer opt-in.
Currently, .gitignore and friends (what you call versioned) are project-wide. Anybody who follows git.git uses _the_ .gitignore that is from the respository, although they can override with their own .git/info/exclude, which might be a good candidate for "core.gitignore = ...". But certain people might want to share their forked .gitignore without going through hassles to integrate that to project-wide copy. ".gitignore" might be a bad example, and grafts may be better. People interested in Linux archaeology might want to share grafts to let them go back from tip of 2.6 all the way down to 2.4.0 (or before) while majority of users do not share that interest.
Obviously, user.name is private to you, but you would still want to use the same across your repositories.
Once we start thinking about allowing the template mechansim to give default "config" information to newly created repositories, having everything in one file may make things a bit awkward to handle. When you managed to make your colleage interested in git development, you can let her copy your remotes/junio. Once you moved remotes/ to .git/config file, while you would not want her to use copy of your .git/config verbatim without updating at least user.name, you would want to have her use other pieces in the .git/config, including [remote.jnio] bits.
The following comments are not about your patch but I am having a feeling that we ended up having too much flexibility. It may not necessarily be a bad thing when we view git as pure plumbing, but it makes things confusing to have too many "you could do it this way if you want to gain XXX, as long as you are careful about YYY".
For example, we do not define how checked-out tree, repository and object database _should_ work together. The officially recommended way is to have one object database at .git/objects/, possibly borrowing from somebody via objects/info/alternates, which hangs under one repository (.git), and the repository can have one checked-out tree associated with it.
However, it is possible to symlink .git/objects to somewhere else, to share an object database between two repositories, as long as you are careful when pruning (you can lose objects the refs in other repository points at but you do not).
Even worse (or better), you could symlink everything except the HEAD and index file to somewhere else to have one repository with multiple checked-out trees (I believe Daniel does this), as long as you are careful when pulling/fetching (fetching into a branch that another working tree has checked out will move the head commit there without updating the index).
Another example is the assumption we place on completeness of the refs. We pretty much declares that if there are some objects you cannot reach starting from your refs, your repository is corrupt (incomplete). But such an incomplete repository can be useful in certain situations, and some things work properly but not others. I think using commit-walkers without -a option can easily create such an incomplete repository.
The recent "should commit be always utf-8" thread probably falls into this category. We all know things should be in utf-8, but other things are possible as long as people understand boundaries.
Most of the time, what we recommend are the BCP, but knowledgeable users can deviate from that, to gain some advantage (e.g. reduced disk space using an incomplete repository, convenience of having more than one checked-out trees at the same time, not having to migrate to all UTF-8 system) over the BCP if they are willing to sacrifice something else or their use pattern is not affected negatively by what they are losing (e.g. can live without an access to ancient history, be very careful when pruning and fetching, do not have people whose names cannot be spelled in KOI-8).
Johannes Schindelin
