WYSIWYG embedded editor and preview for markup languages like: LaTeX, HTML, MarkDown will be great feature which many people wanted like me :)

The spell checker functionality is awesome, but it would be even better if it could use the system spell checker, so we don't have to add words to yet another custom spell checker.

This was a feature in projects in v.1 but now in v.2 any folder you add to a project has to display as the name of that folder. I know you added the ability to rename the actual folder but I just want to alias the folder in the project. Is this something that could be added easily?

Add ability to pin tabs and moving them by keyboard, like in Google Chrome.

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.

It would be nice if plugins could provide a gutter that is optionally displayed alongside files. An example is information from `git blame`.

This is a suggestion/wishlist for a plugin that would allow a simple synchronization with Google docs as it is a nice solution for keeping some of your files in the cloud.

If there are other similar services I'm not aware of and that can already be setup to work seamlessly with SublimeText, please let me know.

I specifically mention Google docs here because I think it's doable with it's current API: it seems you can export documents in Txt format and you can also upload them to Google docs.

Use case #1:
1. open a document from a list of documents in your Google docs account
2. when done editing, save it back to Google docs
No need to make it any more complicated by doing diffs with the two versions of a document - at least at first a single user could use it for editing documents that he or she wants to have access even on the go (Google docs has a mobile site version that works pretty well for that purpose).

Use case #2:
1. open a new document and enter content
2. save your new document directly to your Google docs account

You'd probably just have to keep in mind that you'd be editing only Text documents and not Google docs native format documents.

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.

Please add support for RTL langueages in the next version.