... and thank you for not fobbing me off to a plugin.
I can't see anywhere or anyway to within the platform or revisions to make this happen without resorting to the risk of a plugin.
Again, as @Ipstenu states, I think you discredit the idea of using a plugin unnecessarily. In my experience it appears plugins have been made the scapegoat of inevitable problems with WordPress that arise out of 70 million sites using it, many of which use it differently.
Most often those who are preaching that plugins are bad are those who really don't understand how plugins work compared to themes or WordPress core so plugins find themselves inappropriately being the frequent target of demonization. Frankly, the person most hurt by a distrust of plugins is the person who needs them but because of a bias against them chooses not to try them.
People who won't use plugins are a lot like a Steve Jobs who wouldn't get conventional medical treatment for cancer. And you see how well that worked for him.
where a current static page stays live while a junior account exec makes alterations and saves their work for a superior to approve.
As @Ipstenu pointed out, ~80% of people likely don't need what you need, and of the 20% who do need it, many will need it to work differently from the others who need it. I count myself as a pretty hard-core plugin developer and yet I don't see one obviously correct technical solution nor one obviously correct user-experience for what you are discussing.
Posts always have a "most recent version" and that most recent version is either published or in some other status that is not published. What you are asking for instead is either the ability to branch posts and revisions, assuming you want to allow more than two people to work on alterations, which can get pretty complicated and would likely require non-trivial changes to the WordPress database structure, or you are asking for a staging feature.
We are actually addressing this for one of our clients but it requires two installations of WordPress, one for the "live" site and another for the "staging" site. The live site waits for content to be approved and the staging site is where people are able to edit content without having to the unapproved versions viewable. There is a commercial plugin we are using at the core of our solution called RAMP.
We decided against having staging built into a single site because many of WordPress' internal assumptions assume one current post, not several and we felt every way we could implement built-in staging would be inelegant, so we didn't.
I also ran a test (based on your last informative post) to see if revisions are part of XML import and export and from what I can see they are not. This would mean that a backup retrieval situation (eg. caused by a hacker) the immediate disruption is solved but revisions are lost. Its worth noting that a history state of a stack structure in the existing tabled data as I described could easily be incorporated into XML import/export. The pages in the history stack being flagged as draft except for the live one.
I'm pretty sure that nobody who is serious about their WordPress site uses XML exports for backup. As @Ipstenu said, backup your MySQL database instead. We've been using the commercial plugin BackupBuddy but I hear BackWPup is good, and there are a lot of other backup plugins that are good too. And if you don't want a plugin, buy a copy of Navicat or similar and download your MySQL database directly (I use Navicat daily.)
Therefore I still think there is merit to my original suggestion and I hope the core dev's see likewise or can adapt the idea into something better.
As someone who has made literally hundreds of WordPress feature requests over the past 3 years I have a little experience here. I can't tell you what they will agree to add but I can pretty much tell you what they won't add and your request is one of the "won't adds", at least any time in the next few years, if ever. Most bloggers (~80% of WordPress users) don't need this functionality and since it would add significant complexity, WordPress won't be adding it. Sorry.
That leaves you with the following mix-and-match potential solutions:
- Learn to love plugins and find plugins that (mostly?) meet your needs.
- Modify existing plugins and/or build plugins yourself.
- Hire someone to modify and/or build the plugins you need.
As an aside, in my experience the lion's share of the ~20% whose needs the WordPress core team are not addressing are business users who have more advanced needs. Because I'm in that ~20% and because I like to build solutions that can be used by a broader community my team is planning to launch a series of free GPL plugins designed to address many of the needs of the ~20%.
Our business model will be to find companies who both need and are willing to pay for the features that the WordPress core dev team won't add and then add them to our group of plugins we'll be distributing for use by every one else who is using those plugins. And we plan to have a beta in early 2012. FWIW.