As I understand it, 0.8.6 raised the maximum block size from 300KB to 350KB. According to current charts (http://www.quandl.com/BCHAIN/AVBLS-Bitcoin-Average-Block-Size) this maximum will be reached imminently.
There is currently no community consensus on whether to raise the block limit, but if this is not done, many investors in bitcoin (who are investing on the understanding that it will operate as a currency) are about to lose confidence, and the price will likely drop significantly. However, if sufficient nodes, exchanges and merchants (many of whom use bitcoin like a currency) when the metaphorical bitcoin boat hits the iceberg, it can split in two rather than sink. Exchanges can prepare for this event by being ready to trade both versions of bitcoin post-fork (as well as requiring people to clarify which version of bitcoin their buy orders are for prior to the fork happening) and the market will automatically derive on the prices of each type of bitcoin. The two bitcoins types that emerge from the fork would both be useful and needed, with the upscaled one providing more day-to-day currency qualities whereas the unscaled bitcoin (350K limit) would provide less frequent transactions and would continue to be able to run on lower-spec hardware.
I believe action needs to happen as soon as possible as it may already be too late to avert significant impact on the network once the average block size required exceeds that which is available.
Waiting for a consensus isn't ideal as this is unlikely to happen across the entire bitcoin community. A hardfork with two bitcoins is far more likely to survive the limit being reached than only one which will struggle. A analogy would be diversity in crops surviving adversity better than the hybrid crops which were not genetically sufficiently dissimilar.
In the same way that the inadvertent hardfork of last year was managed, I think with sufficient community collaboration this could happen in a timely manner, only this time it lacks the same sort of urgency and is more preventative than reactive, that is, unless we wait. (Frog in boiling water analogy comes to mind).
The code changes for this could be minimal with the focus simply being to increase the block size to something that will survive beyond the current limit, perhaps using an algorithm to set the max size to a slowly increasing amount based on the average over the last 2 weeks.
I think this is important as many of the bitcoin advocates I meet recently are advocating bitcoin as a currency for use in situations such as buying relatively low-cost items (e.g. a cup of coffee) and so due to this lack of understanding that is prevalent within the bitcoin community, it may be that this assumption about the use of bitcoin forms the majority of investors currently investing in bitcoin.
In order to implement this, there could be a simple command line argument to set the type of bitcoin desired, no actual fork of the project would necessarily be needed.
Suggested names for the twp bitcoins might be: Bitcoin Gold and Bitcoin Currency, Bitcoin 1 and Bitcoin 2, Bitcoin 1M and Bitcoin 1G. Just suggestions. The name is less important than the urgency in implementing this, but it's pretty important to avoid confusion. (Technically Bitcoin 1M is incorrect given that it's currently 350K).
