The different bonus behaviours are a machine behavior difference: If a TE pulverizer pulverizes a forge compatible Ore, its going to apply its own defined bonus material logic, and it wouldn't matter which forge compatbable silver dust it generated.
I actually had in mind differences in actual code -- which is what I term 'behaviour' (your example was of differences in recipes). Let's take another (contrived) example: a mod comes along adding a Uranium ore, and specifies that when the ore or its ingots are in your inventory, they slowly decay, dealing damage and the occasional nausea debuff. How do we unify this with another Uranium that doesn't do this? Either all uranium becomes this radioactive stuff, or else you lose the decay mechanic.
I see two practical issues with my idea:
1. items with multiple registrations.
I hadn't thought of that one, but you're right that it's another major issue. It could theoretically be fixed by MineTweaker (it can mess with oreDict registrations), but no default behaviour seems to work well aside from not unifying the items in the first place.
2. "high quality" items that are registered for downwards compatibility. Blue Slimes from TiC come to mind: For extra utility they can act as green slime in many recipes, but as they are rarer than green slime, there are a set of recipes unique to them.
HLSA steel from Rotarycraft is an example of a mod author "Getting it wrong" and trying to force users to use 'their vision' of steel production, but also forge registering it so it can be substituted in other mods recipes. If every mod author took that approach then we might as well not have a forge dictionary (In case its not obvious, RoC *only* uses its own steel in its own recipes).
Yeah, both of these examples show that it's good to keep the existing ore dictionary behaviour in most cases, but allow some secondary form of unification to occur iff a mod decides it would be appropriate. I could see it also including a set of generic ore block and dust/ingot items built into Forge itself (mods would still be responsible for providing art, but the behaviour (ore blocks drop themselves, dusts and ingots do nothing) would be pre-determined).
The best solution I've seen so far to the problem was
a mod initially published on the IC2 forum that would add a post-processing step to the world, replacing ores with a single variant of themselves after generation, as well as replacing items in dungeon chests to provide a single kind of, e.g. copper ingot. It also went through vanilla crafting recipes, furnace recipes, and IC2 machine recipes, forcing all of them to always output the same variant (and using the ore dictionary to tell when it should apply). Back when IC2 was the main set of machines I was playing with, this pretty consistently gave me only stacking ingots for the same ore, no matter its source (and this was when TE got its good-looking ores and ingots, so I had configured the mod to unify to those).
Edit: OreDupeFix doesn't fix the previously-mentioned issues, though, and it's not really any different from the proposal of having Forge do the unification itself. It was just the closest I'd seen this idea come to fruition.
