I suspect it's just the behaviour that's slightly different.  When you have a single-document window open (i.e. not a project or folder set) these "new document" commands actually open a new window to perform the action.

Making it configurable will likely be the only way to make everyone happy, though.  :/  (I like window consolidation; I keep notes in untitled documents tabbed in a window in the left third of my left-hand monitor, the active project in the remaining two thirds of the same.)

For web browsers and such the ⌘N / ⌘T shortcut separation makes sense; you're not really creating documents in that context, you're creating windows and tabs explicitly.  In an editor, however, tabs are naturally associated with specific files; creating a new tab without a file selected in it would make no sense.

Edited to add: and thank Eris you went with tabs-as-files instead of tabs-as-workspaces and have currently avoided exposing "active files" as a discrete element to the user; it adds a whole lot of confusion in certain other programmers' editors I've used in the past.

Due to the fact that my development environment automatically reloads source code when the files change on-disk I have globally disabled Apple's new autosaving feature; it was causing nothing but headaches due to syntactically incorrect files being saved on a regular basis.  Also, due to window restoration behaviour being extremely aggravating in 90% of the applications I use—notably development tabs in Safari and the many tabs I have in Terminal being restored incorrectly—I have also enabled the "close all windows on application quit" option.

The latter window restoration problem is a weird one: Terminal tries to track the current working directory of each window, but due to the fact that I'm using virtual chroots and some advanced zsh trickery to isolate work environments it never gets this right.  Ever.  ;)

Edited to add: I do appreciate the options; for end users who only really need to worry about e-mails, desktop publishing documents, etc. I can wholeheartedly recommend full restoration and autosave.  But not for a developer such as myself.

Ah, no, the spaces shortcut is control+arrow keys, not tab.

This ticket is unfortunately broad (multiple issues) and reports issues with features that don't yet exist: there is no current FTP connection support…

With the (now existing) ability to open folders you can easily right-click either sub-folders or files and open them in a new window.  Thus multiple tab sets.  If you have an existing window and want tabs in a new one, open a new window using the File menu or relevant shortcut.  (From testing the last created window is where new files are opened by default.)

No idea what "notes on top of the editor" or "special colour" might be referring to; do you have a mockup of what you'd like?  I use Moom to arrange my windows on a grid, allowing me to easily have two windows each filling half the screen, except a small strip on top of, say, the right-hand window allowing me to place an additional window for notes.  (Or another application, like the notes app.)  Window arrangement like that is somewhat outside the scope of a text editor, though.  ;)

I'd recommend voting up the other tickets (like the FTP support ticket) if you desire those features.

+9001 -- the other "selections" though should be quite visually distinct.  E.g. a two-pixel border in the selection colour instead of full background highlight.

A scripting engine could solve this one pretty fast.  ;P

You would URL open the .pkg contained within your app bundle, this should hand off the file to the system-wide Installer.app which would perform the privilege escalation necessary for installation itself.  I haven't tested this within a sandboxed app myself.

Split view has more implications than just putting two windows side-by-side.  You may wish to split the same file vertically to simultaneously edit one section while viewing another.  The way Chocolat handles basic splits is fairly intuitive: either explicitly create a horizontal or vertical split from the File menu (same file, two views) or simply select multiple files from the directory listing for different files.

If you're handling splits as completely separate windows there is very little way to control them using keyboard shortcuts without the use of additional software like Moom, and even then management is more of a pain.

That latter point is also dubious.  Now that I know that adding a folder adds to the current window's side-bar, and that I can right-click to extract that subtree into its own window, I've got less of an issue.  You'll notice in my original video that the newly opened file does not get added to the side-bar.

However, by opening multiple (potentially very disparate on-disk) trees in the same window you may run into problems in the future if/when you try to implement project-like features.  Managing a virtual filesystem of project structure separate from (and potentially unrelated to) on-disk structure the way Xcode does is a headache.

The difficulty isn't that the original (single-click) file goes away, it's that a file from an entirely different directory tree was opened in the same window.  I'm aware of the double-click persistence.  "Open files outside active directory tree in new window."