When trying to chisel a modded block with 2 Ore Dictionary names, chisel only picks the first, so it doesn't detect other variants.
Example 1, with a Basalt stone:

Example 2, with Marble stone:

Yes, because it makes no sense for one block to be in-between two groups. There are two parts to this limitation:

1. There's not enough space in the GUI for both oredict groups
2. This would allow changing ANY stone into ANY marble (etc for other doubly-registered blocks) using this block as a proxy.

Whatever mod adds these blocks is using the oredict incorrectly.

Well, the oredict is a forge thing, and they do exactly this a few times.

The mod that does this is a special version of Mineralogy, a mod that overrides stone generation with it own stone types.
For that matter, it needs to have at least the "stone" oredicted, so you can make stone tools and things that require stone in crafting, as there is no stoneBlock in the world. And I need the stone type oredicted to be able to use mineralogy variants in other mods.

If it where posible to specify a order in the oredictionary it really wouldn't be a problem, as the only thing I need in this case is to be able to change each stonetype to chisel it, but as forge implementation on getOreIDs uses a HashSet (or any other reason that I really can't understand), the order is practically random.

It's an odd heuristic, but perhaps it'd work to use the longest name instead of the first?

The way people use the ore dict, that would usually be the most specific one. And if nothing else, at least it'd usually make the registration mostly predictable. Sort the list to fix the 'mostly'...