Thanks for clarifying that the bug has been around for a while, but otherwise, the reply was needlessly condescending. The issue is the back-and-forth lag, combined with manual updating because an expected feature is not behaving as it’s supposed to. It’s silly to oversimplify it as just a couple of clicks and a trade-off for using eevee. You yourself acknowledged it’s not behaving as expected because of the bug.
It’s not the same as compensating rendering features between eevee and cycles. ~We could possibly be experiencing the same bug in cycles, but because of the override built-in for cycles render settings we may not even be aware if the bug is affecting cycles.~ Update: Tested without simplify in cycles, the bug is fixed in cycles apparently, but not in eevee. They probably patched cycles because it is the main render engine for blender. Most people with high end hardware can handle eevee without patching so its not reported enough for it to be a priority fix, in fact it’s probably because of the reports they also gave texture limit override for cycles. This farther proves eevee could benefit from dedicated override under simplify render settings too.
The lag as it loads high-res textures on switching limit and then again on rendering with it is an issue, not simply a couple of steps, switching shading mode adds further steps to something that shouldn’t even be an issue to begin with. Let’s not forget, one of the main reasons for using eevee is to have a close-to-production level preview while working as well as speeding up render.
If you are wondering about a use case, think of an animated scene involving scenes from multiple angles. Or a webcomic scene where we have to tweak and iterate quite a bit. I find going back and forth on rendered eevee scenes on my projects and lookiong into the bug, quite a few others are troubled by lack of texture limit override for eevee and no suitable workarounds or scripts. Not everyone can afford high-end systems. So, it’s best not to consider other’s genuine concerns as trivial.
Ideally, we should only have one delay during the render. That’s how it works with cycles. With Eevee, it should be like that, but much faster render after it loads resources. I feel you are being intellectually dishonest, and just by the tone of your reply, it was not in good faith. I’m disappointed to come across such a discourse in this community. Most of your reply could’ve been omitted as being condescending takes us away from the real issue and only demeans the one asking for help.
I’ll work on a script and share it for anyone interested to add a texture limit override for eevee under render settings, just like in cycles.
Update: I couldn’t get a script working, going to take a while to figure it out. I’m only an intermediate dev and don’t have any experience scripting for Blender. I’ll ask around some of my dev friends as well.