This is, in some ways, the unseen benefit of 'patterns' in software. [^0] Outside of certain problem domains or extreme requirements, the basic patterns work well enough for a variety of tasks with the right mixing, you usually get introduced to mundane patterns quickly [^1] and over time you move on to advanced pattern abstractions.

I do know that with Descriptor languages and 'libraries' for chip design they reuse blocks and patterns, I think the challenge they run into however, is the possibility that there is cruft built on the existing setup for circuits and the like, and tweaking such may have impacts to downstream customers, possibly undiscovered until after tape-out.

^0 - Even if sometimes they get mis/overused on a low level. By that I'm referring to cases where someone learning patterns thinks they -have- to use all of them.

^1 - Examples that come to mind would be the 'Grab from queue, do thing, update queue', 'Manual' ETL, and 'Timed Jobs'. The last of which is the most fun to see across orgs, as it tends to have the most derivation between orgs. The most slapshoddingly-functional of which being a bunch of scheduled tasks in windows server (which honestly, worked great for them and their use case)