Risk analysis is not a "law game," it is engineering, and a fundamental part of building safety critical products. Software development has historically gotten away with ignoring risk because - outside of specialized domains - the worst of the worst case scenarios were broadly acceptable. But when a developer moves into those domains, the worst case changes from "oh no the website is down" to bodily harm. They should expect to step up their game.
Turning a risk analysis into a deliverable suitable for interfacing with federal regulatory bodies is actually fairly easy. You're just generating a report on engineering work you already did. It's only hard if you want to get away with not mitigating risks (or high levels of residual risk). Because if you document the risk, it serves as proof the engineering team knew about the risk when the product was brought to market.
You're conflating law and risk. One turns out to be a reified political thing reflecting the powers that be of times now and past, the other thing is an engineering concern. I'm quite personally familiar with the specialized domains of which you speak. I would say that our personal ethic of engineering quality totally dominated any legal questions. I'd guess we could have smokescreened any legal paperwork if we really wanted (cough, BMW emissions scandal cough). But, we didn't! We cared, as a company.
Re comma.io - having to play the legal game is a substantial existential risk, only mitigateable with very well paid lawyers and a decent PR crew. That's very different than providing an engineering report. I would guess that if they get rolling in China, they will come back and have the funding and will to hire lawyers to sort the problems.
If you want to contemplate the difficulty of doing engineering vs. surviving the law, consider Tesla's issues selling its car.
These particular questions aren't a law game. They are straightforward outputs of good engineering practice.
There is some gap between just wanting to create things and to create things that impact personal body integrity. It is of some concern that in today's software engineering environment that this is even a question.
Turning a risk analysis into a deliverable suitable for interfacing with federal regulatory bodies is actually fairly easy. You're just generating a report on engineering work you already did. It's only hard if you want to get away with not mitigating risks (or high levels of residual risk). Because if you document the risk, it serves as proof the engineering team knew about the risk when the product was brought to market.