There is a distinction between documenting the portions of your app you intend people use, and effectively promising to maintain side effects and accidents of y

There is a distinction between documenting the portions of your app you intend people use, and effectively promising to maintain side effects and accidents of your existing design. mraleph says the public API is documented, which fulfills the obligation an open source project has. However, the discussion here is about side effects of the V8 implementation, as they relate to performance. That is to say, the V8 team is reluctant to do anything that suggests "if you write javascript using this pattern, your code will/will not run fast, but only because that's just how this week's code branch works out". If the team made those sorts of promises with a project as complex as V8, they effectively become locked in to their existing code, unable to change or improve much of anything because they'd be breaking the promises of performance patterns they previously issued. The authors who are working with V8, on the other hand, require those promises to be made. It's not enough for the performance patterns to be documented, these authors need them to be fairly stable as well. It's a tough situation - the V8 authors have made all the promises and documentation that's practical for them to do, but it's not enough to satisfy these other project authors' needs.