The state of the world for OCSP code is bad. Real bad. Unless you're running IIS, or running a home-grown OCSP daemon, you're going to staple bad responses. That is, if you turn on stapling in Apache or nginx, you're going to serve junk to a portion of your users. When you serve junk, in a must-staple world, everything goes badly.
Further, the world assumes clients are well-behaved - they have good clocks, good caching logic, and good OCSP implementations. Unfortunately, those assumptions can all be wrong - and when something's wrong on the client, it could brick sites. We already see this with HSTS and a variety of otherwise fixable errors (such as clock skew) contributing significantly to warning fatigue or user frustration - and it's actually rather surprisingly hard to quantify, on the client, the ways in which the client could have screwed up.
To that end, our focus has been on quantifying the OCSP ecosystem - both in terms of what the CAs are sending (... frequently, horribly bloated responses that often fail basic DER encoding rules), and what servers are doing. We're also exploring how to allow server operators to participate in that virtuous feedback cycle, by providing something akin to 'expect-staple' - that is, a signifier that the server *should* always be sending valid stapled responses, and a means of getting feedback when this is not the case. This will allow sites to further debug and investigate, both client errors and the fact that, again, most of the OCSP fetching code on servers is bad.