It also allows innovative new techniques
Just saying let's actually write the code, make the product, put these innovative new techniques into a beta release and see how innovative they are before we commit to changing consensus rules. If they are good, add them; if not, shelve them.
it doesn't matter when ideas are scheduled, we should only go to market with the best ideas after they have been built and tested.
I like the ideas proposed but you're justifying consensus rule changes based on a 2017 scheduling date. That is irrational. Build the application that's going to use this, run it on a 50 core machine in a network with multiple miners in multiple locations all over the world, validate that the changes are worth it empirically.
You are trying to justify a change that is irreversible based on a narrow band of theoretical assumptions.
Software developers far too often think, because the cost of deploying their code is so low they can deploy it and fix it on the fly. They tend to avoid building something that doesn't get used. This is wrong, Bitcoin is money not software.
In the real world people build hundreds of prototypes.There are multiple theoretical design iterations for each prototype, only the viable ones are developed. Each prototype and every assumption is tested then the empirical data from each prototype is analyzed before committing to Beta testing and production.
The design process goes: 1) concept evaluation, 2) theoretical design, 3) prototype design, 4) prototype building, 5) prototype testing (repeat hundreds of time as necessary), 6) data analysis, 7) redesign - Alpha prototype design and building, 8) Alpha prototype testing, 9) Beta design prototype testing, 10) summit production prototype candidate 1 for market evaluation, 11) schedule release.
ABC developers are jumping form step 2 to step 11, and your justification is a random roadmap that makes ABC the network authority that governs consensus rule changes.
