The ESP8266 Wire library is all bit-banged code, so IT GOES AWAY AND DOESN'T RETURN until it completes an I2C transaction or it detects an error. You can always set it longer in your sketch if needed for an unusual part. The longest clock stretch I've seen recently was in the 20-40ms range, so I'm planning on that for the default stretch limit unless there's a valid reason for a longer delay. I see a handful of posts here, as well as existing tweaks in Adafruit libraries to deal with the older ESP8266 Wire library, and probably 80-90 similar issues on. I'm merely looking for a realistic maximum for the default tClockStretchLimit( ) to eliminate most of the 'But it works with my Arduino!' complaints. The change to the Arduino ESP8266 Wire library won't affect existing libraries or code your stuff will work the same. If you've just randomly increased tClockStretchLimit( ) to get your part to work then you may have been 'fixing' other issues. I'm more interested in answers from the folks here that wrote Adafruit's libraries, or someone that has a datasheet, 'scope or logic analyzer that knows that ' X part needs Y clock stretch to avoid problems'. What's the longest clock stretch you've seen? That's part of why it has a current default limit of 230us.

However, it has a bug with slow parts & long stretches: it doesn't do yield(), so you may get WiFi problems, WDT resets or other 'background' issues. They've already corrected some of the issues previously, and it now supports clock stretch on any of the bits. I'm working with the maintainers for the ESP8266 Arduino code to fix the I2C clock stretch. If you don't know what I2C 'clock stretching' is, please pass this by.

Esp8266 problem with wire library