In reply to mark k..

@weston, you can not rely on changesets since you can not isolate them due wordpress lacking a concept of contextual setting/db/whatever. Every DB write, every code update can potentially make a changeset void, every change (and code changes are impossible to detect) should mark all changesets as "dirty" and not ready for being applied without a renewed inspection. Every comment made, even if it is spam, should made all changesets void because there is no good way to know what would be the impact on the front end.

And there is always the core problem of wordpress not supporting DB transactions. Which means that a changeset might fail due to whatever reason (DB disconnects for a sec) while it is being applied, potentially corrupting the DB. IIRC transactions are part of core PHP only since 5.5 which means core wordpress will probably need to wait 5 more years before being able to use them.

Just the idea of applying anything (semi) automattically without human attendance and acceptance of each stage is crazy if it does not come with a good backup system bundled with it. Blogs can survive a loss of one day due to having to role back from a daily hosting backup, but shops can not.
Changesets might be a viable thing only if you can easily undo them.

... integrated backup system in core is years overdue

Staging is a solved problem in web development for code not for content.

This just exemplifies the core complaint against the customizer right now. Is it a content creation tool? an admin tool? an GUI configuration tool or maybe (since the 4.7 css code editor) a development tool?

When you try to do so many things, which are mostly orthogonal to each other, at once it is rare that you get all of them right, a more likely result is that you will fall short on all of them.