Thanks for your detailed reply Will. As mentioned in my original post, I've listed a range of points raised time and again by others in my circle together with my own thoughts. I'll continue in that vein below...
It's not so much that features introduced in 2016 aren't welcome, more a sense that, given the limited development resources available, they come at the expense of requested features / improvements. That's a judgement call by Sublime HQ of course - I'm just feeding back what I'm hearing time and again.
The first part of your point requires an understanding of the inner workings of Sublime to appreciate and, while no doubt valid, the fact remains that there are hard limitations to what extensions can do with Sublime. Given your request for API enhancement suggestions here in this forum, it seems as though this is on the roadmap. It'd be nice to see a number of those suggestions find their way into upcoming builds.
Given the efforts made to categorise issues on the tracker, it's not hard to weed out bugs, nitpicks and FR's. But I appreciate that some issues blur these boundaries.
Nevertheless here's an example, and although this post is from April 2016 I reported the same issue on the forum, pre-bugtracker, way back in 2013. These sorts of problems are disconcerting and can potentially corrupt files, in this case with extraneous NULs. Another example is sliding marked regions up and down through folded sections which, while not corrupting data, confuses in practice.
These two examples are fairly trivial and have fairly easy workarounds. But there does come a point where you begin forgetting all the workarounds to these edge-case gotchas, and just wish they got fixed.
I also echo kudos to @FichteFoll et al. on maintaining the issue tracker.
These are fair points but, I would argue, not immutable facts. For example, with particularly large files symbol indexing and syntax highlighting isn't necessary, and issues with word wrap, variable width fonts and minimap are all issues that depend upon implementation specifics which could be improved. On sandboxing, few users would open more than 5 windows in Sublime, and modern PC's are more than capable of handling that kind of memory footprint.
I should apologise for using the loaded term 'lame' in reference to code folding. It is useful in its current form, but the lack of language intelligence and not saving folding state is limited compared with other editors, especially given that Sublime is armed with the lexical info needed to implement intelligent folding via syntax scopes.
Unfortunately, remote editing is something that almost every other editor gets right in terms of reliability and performance, and Sublime seems to struggle by comparison. A simple visual indication can be used to indicate remote files/dirs, in which case symbol indexing & local file notification won't be available and goto anything can revert to a more basic form as necessary.
I don't mean to sound argumentative here. Expectations are generally set by the 'state of the art' (so to speak) and Sublime can seem below-par compared with alternatives when, for example, it slows to a crawl when trying to open and perform simple edits on a large file or crashes when editing a file on an NFS share.
I appreciate these points, together with the time you've taken to consider those raised in my original post. In the end, we all want to see Sublime improve and be the best, most performant and flexible general purpose editor around. I look forward to see what the next builds bring!