BTW: Just curious, and maybe our BIP is not needed anyways, but did you have a look at my comment with regards to not-quite hard forking?
Sorry, I spent most the day watching submissions and comments get deleted from /r/bitcoin.
I think a BIP (or something like it) is very much needed. We have to get people to stop thinking about "Bitcoin Core" versus "Bitcoin XT," and just thinking in terms of "do I want to run software that supports bigger blocks?" In that respect, our proposal is ideal because we could show how it would be compatible with both Bitcoin Core
and Bitcoin XT. The node operator just needs to set his block size limit to, say, 32 MB, and his node will always
follow the longest proof-of-work chain composed of valid transactions. Moreover, we don't need 75% of the hash power to run Bitcoin XT to activate BIP101. Instead, we need 75% of the hash power to set that flag bit. That flag bit could be set with a patched version of Core, or by running the version of Bitcoin that we're proposing.
To answer your question about the
not-quite-a-hard-fork idea, I think it's a great! But like you said earlier,
simple is better. We need to be clear that all we're really proposing is to move the block size limit from the consensus layer to the transport layer.
The stuff like my signalling idea and your "BSL governor" idea don't need strict consensus. There could be several competing implementation with various degrees of interoperability. It would still work fine.