Thinking about this more it appears that PlatformIO is designed to be an improvement on Arduino, but maybe was not designed with the thought of doing mission critical embedded development.
Mission critical embedded you control everything that goes into your project. This includes the compiler version, tool versions, etc. At a basic level, if in 5 years you can not build your project and create the same binary exact hex file for the processor you have failed.
This might seem strange, but the reality is for mission critical projects testing takes as much time, often more time than development. So you want to minimize the changes at the assembly code level. As a simplification, if you change one function and can verify nothing else changed, you can then bound your regression tests which need to be ran with some level of confidence that you did not break anything else. If everything in the hex file changed, then you have to do a complete regression test which can take weeks or months to complete. This is a simplification to explain the concept.
What this means is you can not have a “framework” behind the curtains that can change. The framework is part of project and usually checked into version control with project. If it is not checked in with project then you need to be sure you are controlling the revision of the framework such that you can create that binary exact hex file at any point in the future. For example if you buy a new computer (or your hard drive crashes), you can reinstall and still build that same binary exact hex file.
Note I have seen this to extremes, where virtual images of operating systems with tools have been checked into version control. For example one project used a compiler that only ran on windows 95. So they had virtual machine running windows 95 they used for bug fixes to the project. Most projects are not that extreme as that if you control versions of tools and libraries you can control the hex output.
This is what npm does for javascript. For those who do not know about npm, it is a node package manager for doing javascript project development. What happens is that for a project you have package.json file which has two sections one is project dependencies and the other is devDependencies. These dependencies contain a list of libraries or tools (for dev) and the revision that is accepted (‘^’ means at least that revision or newer), see below. This allows you to control the tools, frameworks, libraries, dependencies, etc that you use for your project. Hence in 5 years if you install the same dependencies and versions, then build project you should get the same output. xpm and xpacks is a project that is trying to do this for embedded development, The xPack Project Manager | The xPack Build Framework.
So until PlatformIO can make it where you can guarantee that in N years from now I can load a project and build it to get the same binary exact hex file output, then PlatformIO is more of a toy like Arduino. That is it good for hobby projects but nothing I could personally recommend for mission critical embedded projects.
Example for npm package.json dependencies:
“dependencies”: {
“axios”: “^0.21.1”,
“bootstrap”: “^4.6.0”,
“bootswatch”: “^4.6.0”,
“font-awesome”: “^4.7.0”,
“formiojs”: “^4.12.7”,
“history”: “^5.0.0”,
“lodash”: “^4.17.21”,
“moment”: “^2.29.1”,
“node-sass”: “^5.0.0”,
“react”: “^17.0.2”,
“react-dom”: “^17.0.2”,
“react-formio”: “^4.3.0”,
“react-router”: “^5.2.0”,
“react-router-dom”: “^5.2.0”
},
“devDependencies”: {
“@testing-library/jest-dom”: “^5.11.4”,
“@testing-library/react”: “^11.1.0”,
“@testing-library/user-event”: “^12.1.10”,
“@types/jest”: “^26.0.15”,
“@types/lodash”: “^4.14.170”,
“@types/node”: “^12.0.0”,
“@types/react”: “^17.0.8”,
“@types/react-dom”: “^17.0.0”,
“@types/react-router”: “^5.1.13”,
“@types/react-router-dom”: “^5.1.7”,
“react-scripts”: “4.0.3”,
“typescript”: “^4.1.2”
},