I'll have to ask your forgiveness for my ignorance of how stuff works behind the scenes, I'm still trying to track down some references for where the nether ore behavior I was expecting has gone differently with your interpretation.

I also realize now that my suggestion might have broken stuff for the people who just wanted standard overworld value ores to spawn in the netherrack / endstone rather than the nether/end variants that most mods treat as worth twice as much.

I suspect I might also have set you up for angry posts from other authors as most mods assume an ore will have either the standard ore dictionary name or the doublevalue nether/end name but not both.

Still really excited for the potential of this and I'll try to help any way I can.

Don't worry about that sort of thing. Ultimately, it's my decision to implement new features into the mod, and thus it's my fault if and when things break. In this case, it was just your suggestion. Most of the time when things break in this mod, it's because I've rewritten something that was already working (see #23) without actually taking the time to retest every single setting, every possible feature, and all supported mods with every release because that's just too much for me to handle by myself, unfortunately. That, and this mod is often used with a lot of other mods at the same time. It's just extremely difficult to keep up with how every single other mod author handles certain issues to make sure my own code is compatible.

I'm also not sure what you mean about problems with having one ore registered with multiple ore dictionary names. As a player, I've only ever used the ore dictionary with CraftTweaker and creating or removing recipes and that sort of thing. I'm not actually aware of any game-breaking bugs that might occur when one ore uses multiple names. I always look at the code of other mods when I add support for them, and definitely at least two of the mods I support have multiple entries for certain ores. In the case of using "oreNether" as a prefix in addition to and not instead of just "ore," I feel like that would be inconvenient, only using one entry or the other. If I want to refer to all types of coal ore, I'll use "oreCoal." If I only want nether coal, I'll use "oreNetherCoal."

If that's not actually how things work or what you were referring to, please clarify and feel free to continue making suggestions. I completely depend on the community to know how to improve this mod and take it further.

Just for reference, in case this is what you were worried about: #23 was actually caused by this line. PropertyGroup#getConditions() usually equals two checks: 1. is the mod loaded, AND 2. is support enabled. The bug was fixed by changing it to this instead. OreProperties#isDependencyMet() checks for two different conditions: 1. is the mod loaded, OR 2. does it belong to a custom property group. This way, the texture always gets created regardless of whether the user has enabled support in the config file. So, that was my bad.

I will go ahead and close this issue, as well. Again, please feel free to message me with any other suggestions or issues, or if I misunderstood your original post. I need all the help I can get. Thanks.

Sorry, I was drawn away for a week or two but having now came back with a fresh view I wanted to check back in to pass along info after some deeper investigation.

I think the main point you and I are getting stuck on is whether you wanted to stick to what I am assuming was the original scope of the mod and create a variant of the normal ore that has netherrack or endstone as the backing material but no special characteristics or if you wanted to create a 'netherore' similar to the various netherores mods of the past.

Right now it appears that everything is working for the first case as the ores in netherrack (or endstone) behave like normal ores and process down through the various minecraft recipes and mod machine recipes as if they were regular single yield overworld ores. If this was the goal then it would probably be best to simply remove the netherore or endore ore dictionary tags as it seems they normally don't work if registered onto an item that already has the 'non-netherore' ore dictionary registration. (I haven't tested if the behavior is reversed when the ore dictionary entry order is reversed)

If you wanted to replicate the behavior of other netherore mods there seems to be two issues.
The first is again the ore dictionary tags as running a nether copper ore created for thermal foundation copper by your mod through a tweaker script to unregister the normal copper ore dictionary entry leaving just the netherore entry causes it to then behave like I had expected in mod machines that aren't related to smelting.
Leading to the second issue, I believe your mod also registers a furnace recipe for smelting each variant added so that it smelts to the smelting result of the parent ore it is based on, 'netherores' depending on the author have usually converted into two of the parent ore or two of the result of smelting the parent. I'm inclined towards two of the parent ore as it tends to be nicer for mod interactions outside of smelting and that your mod seems fairly plausible to expand in the future to create variants of ore that don't normally get smelted. I was again able to test this using tweaker scripts to unregister one recipe and register a different one.