I see three issues with the nice ideas presented:<p>1. Incentives.<p>I’ve made my contributions to debuggers (Firebug mostly), and devs are not willing to pay for it (we had donations, but I’ve seen people create projects in the space) and so tool makers (browser makers in this case) eat the cost and see it as a cost center. <i>Because of this, the debuggers are at the abstraction layer of the tool itself.</i> The tools change and the cost of keeping the debugger in sync (usually well after the feature is out there) is already high enough.<p>I put hooks into Firebug to make it better for higher level debugging of frameworks. Later I made a paid extension [*]. It paid for a new computer, and spawned many framework specific extensions over time. I pushed Chrome's DevTools team to add some of the same hooks. Sadly, a decade later, many of those framework level extensions don't use what is available. Again, it is a cost center for the framework development, so just enough gets done, no more.<p>2. Tools are Siloed.<p>You may have OpenTelementry, etc., but that data is siloed off somewhere. The IDE doesn't have it. But the IDE has extensions, so maybe someone like Microsoft can bridge the gap and put up a sidebar that is a heatmap of the time that that code takes on the CPU.<p>3. Levels of Abstraction.<p>When you talk about state and data modeling, not only is it siloed, but the levels of abstraction are plentiful. It is somewhat possible, but I refer you back to 1--Incentives.<p>[*] <a href="https://vimeo.com/showcase/2541003/video/75271334" rel="nofollow">https://vimeo.com/showcase/2541003/video/75271334</a>