I think this is less likely to happen again because Google's policy has changed on shipping new features. With the web audio API they shipped a prefixed version of the incomplete spec very early on (webkitAudioContext instead of AudioContext), and then when the spec was reasonably stable they moved to AudioContext and updated some of the method names to the (now different) spec, which broke content designed for webkitAudioContext.
Nowadays they implement things behind a flag in chrome://flags while it is in development, and only enable it by default for everyone when there's more confidence the feature works and the spec is stable and unlikely to change. This is in part due to loads of sites, especially on mobile, ending up using webkit-prefixed CSS names, and actually skipping the standards-compliant names, to the extent that other browsers like Firefox and IE have to implement the webkit-prefixes for some sites to display correctly. This probably would have worked better for the web audio API as well, since it would have avoided widespread usage of an unfinished feature in Chrome before they finalised it. On the other hand back in 2011 audio support was so poor that supporting the web audio API was essential, and it took a year or two for the spec to finalise, so I don't know if we would have wanted to wait actually...
tl;dr - seems unlikely to happen again on this scale.