Very rarely do the people working full time on a framework/tool also use that framework/tool in a non-toy setting. They aren't working two full time jobs after all.
I think there should be a distinction here. E.g. if you work on a browser, possibly implementing parts of image loading, or javascript parser, etc.
Are you consider a dogfooder if you use the browser? or do you need to lots of write Javascript yourself, etc. to be considered "a user of your product"?
Typically, these are two different sets of people.
I suppose this problem is timeless, back when I was active in the PHP community it was a long-running joke that people who "graduated" to committing to the actual php source (in C) were not doing web development work anymore. And I suppose it was actually true for the majority. On the other hand, designing language features wasn't really related to using it for web work.
Dogfooding doesn't mean you know how to build it. Take for example the graphics engineers on Unreal Engine. They almost certainly know how to fly around test zones or make stress scenarios, but they aren't going to be building large, detailed, open world maps like will be seen in the next Cyberpunk or whatever. And it's not reasonable to expect that of them, either.
Nor are the people doing UI work in Blender going to be able to make Big Bunny.
Nor are the people working on fusion360's parametric system going to build complex mechanical-fluid simulation scenarios.
Flutter is simpler than those, sure, but even in that world you have people that do nothing but fonts & text for their entire careers. They'll know how to do text stuff in flutter, but they'd be lost if you demanded they make a tiktok clone.
Only if you're oblivious to the day-to-day activities of a software project. They work on building a framework, not on using said said framework to build something entirely different that has no bearing in how to build a framework.
> I think the experience of building something atop a framework should absolutely have bearing on how to build the underlying framework.
You'd be wrong. If your job is maintaining a framework then your focus is on internal details, and how the framework is used would be limited to your concerns in putting up test sets.
Believing that working on a framework gives you equivalent or even similar experience to using said framework in professional settings is a kin to believing that all mechanics are excellent drivers just because they work on cars.
It does, however, have bearing. Despite how common the practice may be in the corporate world, developing a framework without any regard to the user experience thereof is pretty suboptimal
This could explain a lot.