To me that's a feature and not a bug. A good codebase would have --noImplicitAny enabled, which would catch this. Relying on usage of a function to know its types is fragile, the function should be the one declaring the types it uses so that callers can adapt to changes, not the other way around.
To build upon your comment, I really like the way Rust does things (they do it for coherence and major-minor versioning changes not breaking inference) - you declare types in functions (you have to) & structs, and everywhere else is optional (unless the type checker can't infer the type).
--noImplicitAny isn't quite equivalent though. What type inference provides is the ability to define the type of something somewhere and propagate that contract throughout a complex system such as a DI container.
The playground examples are just an oversimplication to illustrate the core difference between TS and Flow, but the screenshot gives a better idea of how it actually plays out in practice. In our case, we tie the type to the DI token and a plugin receives something that is guaranteed to be of that type.
This means someone migrating doesn't need to explicitly add types to their code, but can still get better gradual type coverage than `any` or the break-the-world `--noImplicitAny` flag.
I can totally see an argument for that if you need gradual type coverage, which I guess is needed on large code bases. I have only worked on smallish ones of a few thousand lines of code, and it took maybe an hour to type everything, although most of it was really fun and exciting :) but in cases where that's not realistic, I could see using Flow to help transition.
