There are many reasons to stick with a version of Python 2.x.

• All existing Sublime Text plugins are on Python 2.6; Sublime Text 3 has a different API as well as a different language version.  The recommended policy for 2.x->3.x Python upgrades is to allow for the language upgrade to be made independently of the API upgrade.  This is especially important for proprietary systems that have plugins like Sublime, since most plugins don't have a continuous integration systems (Sublime is hard to automate server-side) and are more likely to have bugs that don't get spotted when doing these big upgrades.
• Many useful Python libraries (such as Django, Twisted, Flask, South, Paramiko, html5lib, python-ldap, Selenium, Pylons, and so on) only support Python 2.x, and it is super helpful when developing with these libraries to be able to import them directly within Sublime plugins; this is one of the reasons that I personally switched to Sublime.  At least one plugin (SubliminalCollaborator) uses portions of Twisted that haven't been ported yet, and that dependency will take a non-trivial amount of time to upgrade, even if the plugin itself requires no effort.
• PyPy, a radically faster runtime for Python, still only works with 2.x, so many of these libraries need to maintain Python 2 support for the time being anyway, but Python 3 support has fewer obvious benefits, so they invest less energy in it.
• Specifically regarding 2.7: jumping from Python 2.6 to 3.x is a big jump; moving from 2.7 to 3.x is a slightly more manageable leap.  If you can't do a version of Sublime Text 3 that supports 2.7, perhaps you could at least do a version of Sublime Text 2 that upgrades from 2.6 to 2.7.
  

Since plugins in Sublime Text 3 already live in a separate process, perhaps there could be a Python 2.7 plugin process and a Python 3.x plugin process as well, to allow plugins to transition gradually, rather than all at once.

Please consider restoring Python 2.x support to the new version of Sublime Text.

The ability to override color scheme settings ala CSS would be very convenient. I'd like a mechanism for "sub-schemes" that override only portions of the main, "active" color scheme.

For example, very few color schemes support Markdown and I don't like the looks most of those schemes in other syntaxes, like Python. I can fork my own version of schemes I otherwise like and patch in Markdown support, but then I'd have to maintain that fork. I could use the sub-scheme mechanism to create Markdown-specific overrides and add them to my syntax-specific settings like:

    {
        "color_sub_schemes": ["Packages/My Subthemes/Blue Markdown links.subscheme"]
    }

Those sub-schemes would "patch" whatever color scheme I'm currently using - say Monokai - with just a couple of setting overrides.

This could be a big help to people maintaining language support as they could include a couple of subschemes with their packages like "Mylanguage (bright).subscheme" and "Mylanguage (dark).subscheme" so that users could be quickly up-and-running with their usual, familiar color scheme.

This could also be an accessibility win for users who need a particular setting in place across all color schemes, but otherwise enjoy the wide variety of available ST2 schemes. They could add something like:

    "color_sub_schemes": [
        "Packages/Headings/Bold Headings.subscheme",
        "Packages/Headings/Inverse Italics.subscheme"
    ]

to their global settings so that they can use the same color schemes we all know and love but with convenient accomodations of their personal needs.

It would be great if there was an option for file tabs to be placed at the bottom (or perhaps left / right too) of the window. The current paradigm of browsers prefers tabs on the top, but if your taskbar is at the bottom, it makes more sense for them to be closer to it. Opera has allowed such functionality for eons.

Congrats on your otherwise great product; I love the code "bird's eye"!

It would be great if you supported SIMBL accessibility hooks - particularly so that Keep Afloat (http://infinite-labs.net/afloat/) can work with Sublime Text 2.

This would mean that I can have two ST2 windows open, with one floating above, while I type in the one beneath.  This avoids having to change whatever layout I have in the subordinate window, but lets me see code from the other while I type.