As fredemmott said above, we're hoping to build replacements for the various PHP builtins that we want to be a core part of Hack. I think that replacing the functionality provided by PHP builtins will be a less confusing transition experience than retrofitting them with modified behaviors would.

Once we do have a compelling and comprehensive Hack Standard Library, I wouldn't be surprised if we dropped PHP builtins in favor of that.

> my ask is to just make a better language and drop ALL of PHP baggage.

Long-term, we hope to make pure-hack projects more practical, and we're aiming to make Hack the best web development language. This will take time - both to decide what parts of PHP we want to keep (it definitely does have excellent parts), and how we want to change the things we think need improvement.

> Because why even break support from PHP7 if you don't plan to change (fix) the builtins?

Sorry, I was unclear: changing the behavior of the PHP builtins will break BC with PHP, and the result would still not be what we want for hack. We're likely to build Hack-only replacements for the PHP builtins, instead of changing the behavior of them.

Maybe because there will be replacements instead? I guess that changing behavior (and type signatures) of builtins is not backward compatible with projects that want to use Hack. This way they will be able to migrate at their own pace.