We hear you! We're most certainly planning on eating up the system's chain to describe, version control and validate up the system's chain.
As one example in an earlier (and likely future) permutation of atopile we could compile harnesses (using the fantastic https://github.com/wireviz/WireViz) by linking two interfaces on connectors.
Long future, if you can integrate mechanically too, you can at least check if not generate the harnesses lengths, bend radii, drip looks etc... for that same harness.
Somewhat like software, you can only tractably do that at scale if the units work and work reliably. Unit tests are the basis of software validation and we expect hardware validation as well. We're starting low-level we know, but with a concepts we know (from the insane scale of big software projects) can work on enormous projects too.
Many of the things you mention are not really done in hardware.
For example, unit tests. Even in FPGA designs, you can run functional simulations on portions of a design to help save time and validate. I don't believe we are yet at the stage where we simulate the entire chip. Not sure it would make sense even if you could. You have to worry about real-world effects such as clock skew and jitter that might not necessarily be deterministic. If you have designs running at hundreds of MHz or GHz, at one point you have no option but to run the design on the real IC and debug in hardware.
The other issue is that every company is likely to have their own process for some of the things you mention. Harness design and manufacturing is a good example of this. Companies like Siemens, Zuken, TE and others have professional solutions that often integrad with CAD/CAM tools (like Siemens NX) and produce professional manufacturing-ready documentation. Job shops, in many cases, are setup to receive files from industry standard tools and work directly from them. WireViz is a neat tool, but it is pretty much at the hobby level.
You should not be discouraged though. That said, I would still urge you to interview a lot of EE's and product design engineers to really understand what you are walking into. You need to realize that you are not likely to change the entire product design and manufacturing industry just because you offer a software-like approach to design. That's just not going to happen. Industries have tons of inertia and they tend to only be interested in solving pressing problems, not adopting entirely new workflows. Also, the EDA/CAD/CAM industries are paved with the corpses or thousands of offerings that, collectively, over time, defined how things are done today.
My guess is you'd have to raise $100MM to $300MM, hire tons of engineers and devote ten solid years to materially influence how things are done. Nobody has the time or budget to introduce new tools, new problems, new training and grind their entire product development process to a halt just to adopt a new paradigm.
I'll give you an example of this from real life. The CAM tool we use to program our CNC machines is crap. We use CAMWorks Professional, which integrates with Solidworks and probably cost us $30K+ per license (between initial purchase and maintenance fees). We want to switch to at least doing CAM using the Fusion360 tools. However, this will definitely cause us to take a hit in productivity and possibly put out bad product for a period of time until the dust settles. And so, while we absolutely detest CAMWorks, we have no choice but to continue using it until a window of opportunity presents itself to make the switch. And, of course, also knowing full-well that the Fusion360 solution isn't utopia. There are no perfect tools. Just choices you might be forced to live with.
As one example in an earlier (and likely future) permutation of atopile we could compile harnesses (using the fantastic https://github.com/wireviz/WireViz) by linking two interfaces on connectors.
Long future, if you can integrate mechanically too, you can at least check if not generate the harnesses lengths, bend radii, drip looks etc... for that same harness.
Somewhat like software, you can only tractably do that at scale if the units work and work reliably. Unit tests are the basis of software validation and we expect hardware validation as well. We're starting low-level we know, but with a concepts we know (from the insane scale of big software projects) can work on enormous projects too.