Just saw some comments on the xEdit Discord this morning from ElminsterAU, the primary dev for the project. He's been backwards-engineering Starfield since it came out, tweaking his project to make it work for Starfield. This is important because, as soon as he does, (safe) plugin-based mods become possible, opening up the floodgates for a whole new class of Starfield mods. Only, in its current state, he's not sure he can make it work. Or, for that matter, that the CK due from BGS "early next year" can make it work, either.
The image I've posted is a collection of carefully selected snippets of a much larger discussion, with all the supporting info being excluded for brevity. This is "headline reporting" at its worst, so I encourage anyone tracking this topic to go to the Discord and dive deeper.
Maybe he's having a bad morning after spending all night attempting to decipher undocumented code that is, literally, legacy built upon legacy built upon even older legacy. But if it's really this bad, then the modding scene for Starfield is going to have a much harder time getting started than is currently being anticipated.
Starfield has, what, 1000 planets, and each time you land the engine basically auto-generates a new approx. Skyrim-sized worldspace. The reference system has to have departed significantly from previous games for it to work. Even Skyrim was gently pushing the limits of how many objects can be referenced with the 8-digit refID (roughly 16 billion entries per .esp for all world objects, NPC-s, weapons, armor, outfits, consumables, spells, magic effects, markers, helpers etc etc since absolutely everything has to have a refID).
Of course Starfield is a mess coming from the simple refID scheme of the older games. The reference system in SF must be some sort of convoluted hierarchical system to be able to place probably hundreds of billions of objects over 1000 planets and retain persistency. It won't be easy to reverse engineer.