De-bloat de bloat: nano + markdown => pandoc => ePub. Salt, season, & distribute.
OH! Scrivener? Repository & Reference.
Your points are well-taken. But there is still a widespread misconception, particularly among users of the U------- software, that Scrivener requires users to mess with final output format during composition. Having Real Styles will only reinforce this error.
That said, it does seem to have some valuable utility in your use case (and doubtless others) so I will shut up about it.
From the urban dictionary:
bloatware
A piece of software, hardware or website that attempts to do too much and becomes utterly useless for users. An example of bloatware would be a word processing application that also tries to be your page layout program, drawing tool, and web browser; absorbing half your hard drive and all your RAM in the process.
Mind you guys, this isn’t my definition per se; I’m just putting it out there.
Bloat in software is incredibly relative to the user. I was long time ago a user of Opera (started around 1999), a web browser which took a very opinionated view of the user interface. It came with all sorts of additions built-in: what is now called a tabbed interface, though it actually had a full MDI interface which was much more powerful, mouse gestures, per-site preferences, a sidebar, etc. etc. — basically lots of features. I found all those tools exceptionally useful, and as a Science student took great pride when I could use Opera like a ninja and pull multiple data sources much more quickly and efficiently than others. Opera users were a passionate bunch, and we loved the features that were bundled. However Opera was constantly criticised as being “bloated”. You could easily hide the features, but for some users the “bloat” was conceptual: even though Opera was no slower (indeed the user could be much faster with gestures, solid keyboard control etc), took no more memory etc. many people would refuse to use it.
The analogy I want to make is that even if you have infinite computing resource, and a user interface that can streamline features, some people will still complain Scrivener is “bloated”. That is, to my mind, ridiculous; but their point of view is as valid to them as my point of view is to me. Bloat is metaphysical!
Personally I can’t wait for Scrivener 3. Even though I use MMD for all my writing (thus don’t fuss with styling my text for output at all), I neverthless think a better Styles system is going to be a super useful update for many Scrivener users. I’m very much looking forward to the revamped/unified meta-data/bookmarks/references system which is quite complex in Scrivener at present. And I do want (unrationally) access to the latest APIs, more bits and (rationally) a non-buggy PDF system. Bring it on!!!
I have to say I agree with you on that.
Mark
Straight from the OED (Oxford English Dictionary Online):
Bloatware:
Software that requires an excessive amount of disk space or memory, typically due to the repeated addition of new features over successive versions.
1991 Businessweek 30 Sept. 100/1 Worse, they’ll be stuck with poor applications programs—what he calls ‘bloatware’.
1998 N.Y. Times 3 Dec. d3/5 As long as software developers keep making bloatware, you will need a bigger hard drive.
2011 Lifehacker (Nexis) 2 Feb. I hate syncing with the bloatware that is iTunes.
I think we can all agree that the OED is a tad bit skimpy on the full ramifications of the word’s ultimate meaning!
I understand all but the “nano” reference. To what (software?) are you referring? Inquiring minds want to know…
Oh. A Windows editor. Nevermind.
Oh, so emacs?
ROFL!
But it does require you to mess with formatting after you’ve composed to an external output format, because Scrivener is not a full-fledged layout program (nor does it claim to be). But with “real styles”, that should actually get easier and more straightforward – the kind of hacks Mark does to get things working nicely with NDP should become easier to achieve with .DOC and .DOCX output, because instead of today’s presets just applying one-time formatting to the text in Scrivener, the style information can also be tossed along and matched up to the document template.
This would have been AWESOME for me writing the Exchange Server Cookbook – having Scrivener pour everything out to a DOC that contained embedded style names that I’d matched to the ORA Word template. I could just take Scrivener’s output DOC, attach the template, and have a ready-made document to pass on to the publisher for edits and reviews.
So I’m afraid I don’t see how “real styles” are going to make things worse. I see them as potentially reducing (in some cases, by quite a lot) the post-formatting fiddling one has to do by allowing the style information to be part of the output so that the layout program can slurp it in and do the needful. If other people who want to cheerlead for another program and don’t understand Scrivener want to think otherwise, well, their ignorance really isn’t my problem.
Yeah, this subject is beyond me now. Pleasantly waiting till someone starts speaking English again. 
I love playing with emacs. I do it every year for about 2 months. I start with it, because I prefer writing in vim, but orgmode, so I use vim in emacs, and for a while it’s brilliantly simple, efficient and effective, and then I start thinking about interacting with DTPO and Tinderbox and I have fun setting it all up and then…
… I realise I’ve had two months of great fun messing around learning and configuring the software and not really working, and that the small bits of friction that comes from getting emacs to link to the other programs add up to more irritation over the course of a week than just using the not-very-good OSX text input in the first place. So I go back to standard OSX.
This could all be avoided if we had vim-bindings in Scrivener.
Pretty please?
That would be nice, yes, although for me it would involve a (re)learning curve I’ve found myself longing for the “open in external editor” option so temptingly available in the Research folder-- then Scrivener could just hand off the file and not have to turn itself inside out with various editor bindings…
Sorry the conversation has devolved into UNIX. But when you mention bloatware, alas, you invite us techno geeks in 
and emacs is a bloated UNIX editor-- or was, at one time, an editor…
Back to the subject of bloat,
There are a few objective measures of bloat, and for me that comes back to the ability of the developer(s) to maintain the system. I may be offended by the presence of a feature I don’t use even if it never gets in my way. That’s subjective. If the mere presence of multiple features causes an out-of-memory crash in a generously provisioned system, that’s bloat. If the developers can’t keep up with the maintenance queue, and bugs get more numerous rather than fewer, that’s bloat. If my favourite feature gets deleted in removing bloat, I may be disappointed. Oh, well.
And remember, last decade’s bloat is today’s lean app.
Wait until you see what the system will be capable of doing for MMD and other various forms of plain-text writing. They needn’t in fact have anything to do with the formatting of text, in or beyond the editor. As with many features in Scrivener, multipurpose functions are a way of doing more with less bloat (to stay on topic).
Granted most people will use them to make their font different or whatever, and maybe that will tempt some people into just reverting back into old WYSIWYG working habits, I don’t know—but functionally we’ve always had a very similar system in Presets. At least in terms of the UI inviting one to use them “incorrectly”. For example default presets ship with title and heading formats among them—in a writing system that turns your outline into functional document structure. I don’t think calling the feature something else but basically presenting it in an identical fashion on the surface will make a huge difference in “mis-”usage of the software.
Styles for me will replace a labyrinth of regular expression-based Replacements, some post-compile scripting and other downright hacks of the feature set (like using inline annotations for syntax injection instead of… comments). It might be a new feature, and thus one more tick in the toward-bloatness quotient of the software, but in terms of usage, the workflow itself is less bloated, and isn’t that what really matters?
Inline annotations for syntax injection . . . why didn’t I think of that?
I’m wondering, philosophically speaking of course, could one argue that bloat, due to its relative nature, isn’t… really… any…thing…?
Nah, it’s a pejorative term for software that annoys the speaker by its large and increasing feature set, or in my case, perceived level of bugginess that doesn’t get smaller while the feature set gets larger. As such, it’s no more precise than than any other such term. When L&L say they want to avoid bloat, I suspect it’s that they’re avoiding including every user request as rightly they should to keep their product design focused to what they want to sell and support…
I mean, no one wants to try to make a living off OpenOffice…
So bloat-free is a euphemism for ‘we don’t listen to everyone’?