Since everything is just from megascans, it might make more sense to have 300gb of photorealistic assets stored on every next-gen device, and (UE5) games can just commonly load from them.

Yeah, at a certain point, it probably makes sense to have a giant library of universal assets like rocks and grass and trees. There's no reason for each outdoor game to keep reinventing the universe.

So basically you’re asking for a node_modules for games!

More like a /usr/lib shared across games on the same console

This is Unreal/C++ we're talking about. If the size of some field somewhere changes, your 300GB will need to be re-cooked...

You can do that with Substance. Store images in a library and procedurally generate textures at runtime.

"and it looks like they're finally improved on what was a terrible, clunky, extremely dated UI." doesn't hold true, it's mostly the same UI with a dark reskin. Certain editor hot paths have been reworked and that's about it. The editor is almost exclusively written in Slate, Epic's in-house Window framework/general GUI module. Slate's got a pretty interesting nested MACRO system. Most definitely not data-driven and pretty much as hard-coded as it gets, redesigning the editor for real would be difficult to say the least. In reality most experienced developers don't want a new design, they are happy with the workflow they have and I have to agree with them. I'm generally happy with the "if it ain't broke don't fix it" reskin decision.

> isn't there a benefit to procedural on-demand generation for stuff like this?

Like how demoscenes do it? I would think a huge trade off is the performance hit (and potential delay / popin) of the generation

In a way procedural generation can be tought of as extreme compression!