So naturally, I look into how the new generation stuff works in base mod. It's not easy to understand what's going on at first because it doesn't seem to use a noise layer, it generates noise in a new function method.
The problem is, you did not make it modder friendly.
Enemy related functions are all in global functions, so it's easy enough to just call them, but the new ore generation functions are not, they're all local variables in base/prototypes/entity/demo-resource-autoplace.lua
Bilka sugested I just use local resource_autoplace = require("__base__.prototypes.entity.demo-resource-autoplace") to add them to my mod, and this worked in that I could then call the function resource_autoplace.resource_autoplace_settings() as you do in the base game, but get_next_resource_index() starts again at 0, giving it the same index number as iron ore, causing it to either not generate at all in the worse case, or generate as a ring around iron ore in the base case.
Now in theory you could fix this by adding +6 to the end of get_next_resource_index() and that does work, however, if there are other mods in use using the same fix, you end up where you fight for the same ore spots, one blotting out the others.
My sugested fix... Make it a global, especially the get_next_resource_index() parts, when other functions like those related to enemies are already global(this might have been done in error, as enemy autoplace file contains all local variables in the same way, but enemies.lua defines it as a global not a local. it also doesn't make use of an index number), there's really no reason why you shouldn't do this.
A requirement to fix this would be to change line 9 of demo-resource-autoplace.lua to not be a local variable and line 3 of resources.lua was also not a local, the same way enemies.lua line 5 isn't. these 2 changes would solve my huge headache.
To note: get_next_resource_index() is already a global, but the variable it uses is not. using the global from another mod seems to reset it, presumably because you have to re-include the file in another mod, it resets it back to 0.
A better fix might just be to have the file included as part of the normal data loading process instead of being included by another mod file, and have both get_next_resource_index() and resource_autoplace_settings() both be globals, maybe on the resource_autoplace. table.
Yes, I've spent several days experimenting with this.