What's confusing here is that this is already possible with other configuration files (tested with .sublime-keymap (which has the same scope; it's global) and .sublime-menu) and works quite well (except that you can't override an already existing menu with the same keys in the .sublime-menu file, but that's obviously by design).
I also support the "SublimeText/Packages/User//" method. A great advantage would be to just 'not load' a settings file in "/User/" if that package is not loaded (->disabled) or not in the "/Packages" dir. So options that are required for only for a package wouldn't even be loaded if the package does not exist. Not to mention that this is really cleaner and easier to locate if you do that with all your plugins.
On a side node, something that would simplify organizing the whole settings stuff:
I thought about a menu or rather an actual view that contains all the applied settings (and keymappings) but separates those from different files. So you have kind of 'special view' that in fact operates like a scrollable multi-row view with headers (not as high as the tab bars). Probably in the order of precedence (Package/Default->Package->User->User/Package; or whereever these files are located as well).
Think of it as a tree view. You have the filenames as parents and when expanded you see the file's contents and edit it just as normally.
This could even make debugging of your settings easier, e.g. you can determine if a setting was overridden or if it was even "included" since it would have to be present in that view somewhere. And if it's getting to messy you can edit the files manually just like it was before.
Furthermore, one could gray out the overridden settings so it would become even more intuitive, but otoh I don't think this is what sublime is built for, so the above should do it already.
What do you think about that?