Not so much overengineered as it is a task complexity mismatch. If it's coming up often enough that you're seeing benefits, it's likely -- in my experience -- that the very thing you are doing with PHP (or JS for that matter) is just wrong.

It's either the wrong tool for the job, the wrong logic for the job, or the wrong place to be doing the job.

I see this a lot with people doing stuff client-side that has ZERO business client side, and vice-versa. From the numbnuttery of failwind and bootcrap putting stuff in the markup -- and therefor server side -- that has ZERO business there, to people trying to do data processing client side which is 100% ermagahd aherpaderp.

What you've said throws up HUGE warning flags for me, like having a database schema that "changes frequently" is in my experience a nasty double-whammy of "security, what's that?" and "Wow, your table organization sucks". I'm NOT saying that's what's going on for you, but just what you said makes me knee-jerk into thinking that. It sounds like you made a problem you didn't actually need to have, and are throwing more code and more complexity at it instead fo rethinking or refactoring the actual issue.

I mean the only reason I could see for what you describe is if you're literally writing something like a JavaScript version of phpMyAdmin

And even then the handful of corner cases where it would matter don't warrant or get fixed by typecasting.

Though you're right, I do extend it to webpack, and react, and a lot of other bullshit people rely on where in my experience you end up writing twice the code or more, over twice the time, and still barely accomplish the task at hand.

There's this horrible tendency right now for people to treat symptoms instead of causes, and throw more code and more tools at problems instead of... well... just plain fixing their problem.

...as to making a list, it's not a bad idea. Good topic for a future article.