One of the problems with designing game-specific GUI features - particularly inventories - is every game does it differently and needs something customised to the particular game. This makes it really hard to design a general-purpose feature that covers it adequately. Even if we tried I am sure we would then be dragged in to a rabbit hole of endless customisation and extra bells and whistles that everyone would want for their game. GUIs are a vast and complex area just by themselves - enough so that there are entire companies out there whose sole product is a GUI library. It's easy to sit back and say "they should just do XYZ!" but I think this would really be a huge project with significant opportunity cost (displacing multiple other major features) and risk (what if after all that work it still doesn't do exactly what your game needs?).
Construct's philosophy has always been to provide the building blocks to make your own games, and not just hand you "cookie cutter" features that are basically the only way you're allowed to do things. For example there isn't a "Turrent Defense Game" object that handles the entire game for you - instead there are a series of individual features (pathfinding, turret behavior, etc) that can be composed together to make a turret defense style game. This is a much more flexible and powerful approach.
There are already several options for building GUIs, including using sprites/9-patches/etc on a GUI layer, using HTML in an iframe object, or using the new JavaScript feature. If these are inadequate I think the best approach would be to identify the kinds of building blocks necessary to make it easier to design your own GUIs. I do think it would be madness to try and invent custom layout systems in the Construct engine when HTML already has lots of mature and sophisticated options for doing that (e.g. flexbox, grid layout, tables etc). So maybe the focus should be on how to best integrate HTML with games for the purposes of GUI. I have to mention though one of the risks of the "show custom HTML" approaches is that you have to be very careful with handling user input otherwise you create an XSS vulnerability that allows attackers to hijack user's logins, private data etc. from your site/game. This is the main reason we focused on the iframe object for displaying custom HTML, since if you sandbox it it's safe to show untrusted user content in. As ever that shows there are many other aspects to think about and the obvious thing to do isn't always necessarily the best idea.
There's also the feature suggestion platform where you can post ideas and see if they collect votes, which would indicate broad support amongst users and make it more likely we'd consider it. As far as I can see from a quick look there isn't anything highly voted there that already covers this. However I would emphasise that you need to consider all of the above when posting a suggestion - if you just post "make a GUI feature" that is far too vague and vast in scope to consider.