For this reason, I think it would make sense to begin work (and it will be a lot of work!) on developing a working document, or some kind of mutually agreed upon standard that goes into greater depth than satoshi's paper on defining the nuts and bolts of what exactly Bitcoin is.
There isn't anything wrong with what you are proposing, aside from one thing: your proposal is completely skewed into the technical realm and into the total ignorance of marketing and game theoretic issues.
I'm an engineer by training, but I understand the language of business managers and marketing people. Unfortunately they rarely read this section of the forum, therefore you will normally not get the broad feedback that you desire.
What you are proposing is producing something akin to:
#define HASH(x) sha256(x)
#define P2PPORT 8333
#define RPCPORT 8332
Nothing wrong with the above. But because it is open source somebody will soon transfer it to
#if defined(BITCOIN)
#define HASH(x) sha256(x)
#define P2PPORT 8333
#define RPCPORT 8332
#elif defined(LITECOIN)
#define HASH(x) scrypt(x)
#define P2PPORT 9333
#define RPCPORT 9332
#elif defined(IXCOIN)
/* ... */
#elif defined(I0COIN)
/* ... */
#endif
In other words, you've magnamiously forfeited the advantage you had over the competition and commoditized your core product.
Maybe for the moment think of BTC as KFC (Kentucky Fried Coin) and your intention to publish a detailed information about the formula for the Colonel Sanders' secret seasoning and the process of how he arrived at it. You will immediately spawn numerous competitors peddling their version of Fried Chicken Coin.
If you don't like the above analogy then maybe think of how you would like to differentiate your Coca-Cola Coin from Pepsi-Cola Coin and RC-Cola Coin and whole slew of other immitators.
As an engineer you were probably trained to think that your goal is to minimize the number of defects in your software. Try for the moment to think like a CEO and maximize the stock price of your enterprise.
Do you see the problem now?