Hi,
In #9 there are missing files for example for MIMXRT1064 fsl_cache.* is missing

Drats. I've only been starting to test with rt1176 so far myself.

I'll have to take another look at the new SDK files, see if there's another way those particular drivers are referenced / sourced from common.

The weird discrepancy between chip sdks downloaded from SDK builder vs the official GitHub structure is horribly confusing and difficult to manage.

I'm not too sure how the existing chip folders were sourced / updated to be honest? I'm not sure if they were just manually downloaded from SDK builder nor which drivers / middleware would have been selected when they were.

This is my effort to bring some consistency and traceability to this SDK repo, hopefully I can achieve that without breaking existing projects using it too much...

I do not have the answers, I am too straggling with understanding what NXP is doing.
They have so many common files between products, instead of duplicate them over and over they could have created smarter structure.
I gave up using their git repo and always download their SDK once they build it.

I guess the structure of the git repo is their attempt to reduce duplication!

From what I can see It's generally structured with only chip specify drivers in the individual folders, then cmake include files to reference the relevant common drivers.
I'd much prefer something like a json file being available too to reference common drivers, I really don't like cmake personally.

This structure makes far more sense to me and is hopefully indicative of their future path, but it's a shame downloads from other sources mix all the drivers into one folder rather than maintaining common vs specific folders structures.

I generally work on medical products in a regulated environment where traceability of code is crucial. From this I strongly dislike and kind of manual download / unpack / reorganise process for updating libraries, it's so hard to document where and how they've been sourced. Even worse when the download comes from a builder website that custom packs things from user settings - this prevents automation and recording of download links etc.
It's handy for hobbyists who just want to get something going ( and helped me have an impressive demo running on a new dev kit within minutes ) but terrible for ongoing product support.

I had an interest in this for micropython, but now I see people are working to remove this dependency in favor of direct upstream use see: micropython/micropython#11516

What is your use case?

Thanks for that link, I too am coming at this from the micropython direction. I hadn't seen that PR where the rework effort to migrate to the official submodule has already been done!

I would prefer that really, even though it's a large submodule it's the official source so should be the correct way forward.