Your comments

That's true... Temporary workaround, in an on_new or on_activated event listener, check if you're running, if yes, return, if no, start your service. I'd *expect* someone using sublime to click the window, or open a file at SOME point before requiring your plugins services.
Right, so it wasn't just me being high on insomnia... Could've been the case, though.
In case of SublimeGDB, he just if's his way through using .has(), but using the get method with a default value like you did is cleaner (Well, gotta admit that the "sublime.active_window().active_view().settings().get("foo", sublime.load_settings("Plugin.sublime-settings").get("foo"))" construct itself can look pretty confusing too, though. That's waaay to many methods on eachothers tail :P)
Sounds like you are right, and if not, developer should give an explanation (or documentation..?) to help on the subject. *UPVOTING* to get his attention.
I can't tell you the exact setting in use, but overriding plugin settings through project settings should be very much possible - I believe I am doing just that at work. However, my tired brain is getting fuzzy.
For CTags and SublimeGDB, I have per-project settings to set executables and commandlines. The default one is "executable", so that'll never work, and the setup works just fine. Of course, my very tired mind might be messing around with me, and I might be forgetting an important detail.
Agreed, more events should be made available. I'd love some events on which you can subscribe on a view, window or project, instead of having to check if things were meant to be seen by you. Of course, global-scope events are still good, but for some things that belong *ONLY* in a view, or in your case, window/project, it means that everyone with a listener needs to check...
Well, I suppose it depends on the specific order of which things are fired - if on_close is *when the view has closed*, then there won't be much of a view to query. However, if it fires before, then you should have something to play around with.
I agree that 2.7 would be more interesting than 2.6.
2.7 brought quite a few "convenience" updates, and have broader support... And seeing we use an internal interpreter, nothing really sets the limit. OS X bundles 2.7 as well, so there wouldn't be an issue there either. 2.7 is simply better.
I still think that an external interpreter on linux would makes things more fun... One can hack around the limits of the modules, but it does set a few limits... If not on functionality, at least on the ease of development.