With 1.13 introducing tags as a similar feature to the current OreDictionary provided by Forge, there are good reasons to drop support for it. If it is not even dropped by Forge itself.

This is mostly in regards to crafting patterns, which results in a some requirements for actually switching.

1. There needs to be a way to lookup a recipe using a crafting grid/inventory. E.g. using minecraft:white_wool should match a recipe requiring #minecraft:wool for this particular slot. Otherwise there is no sane way to validate recipes and we would have to drop support completely.
2. Currently there are still discussions about a shared namespace for forge, but it's mostly about what name to use. But it is necessary to avoid having to deal with te:copperIngot, ie:ingotCopper, and eio:copperBar or similar.
3. Items/block can be tagged with multiple tags, so oredict:fluixCrystal and ae:fluixCrystal are totally fine to be used together. Hopefully any lookup will return a unique recipe, otherwise we would have to prioritize them somehow. E.g. prefering any oredict version.
4. Tags are way more lossly defined than the oredict. E.g. it can be used to tag a method for ticking. This seems to be intended for command blocks or similar, but worst case it could also indicate an item should tick when inside a player inventory. This might require some sort of blacklist to avoid some buses suddenly considering any tickable items as equal.
5. Buses also have to be considered on how they handle 3 in combinations with a fuzzy card. E.g. a ae:green_smart_dense_cable could be tagged as ae:cable, ae:smart_cable, ae:dense_cable, and ae:green_cable. This is fine for recipes, as they should provide a way to validate the inputs according to 1.
   But this will not exist for buses. Therefore it requires some safeguards. E.g. only use fuzzy for items with a single tag or a single oredict: (but multiple mod specific ones). Handling every single tag is simply not an option, as it will make it impossible to only export an fluix crystal, should the filter item also tagged as ae:pureCrystal and thus exporting certus/quartz crystals.
6. Requires some changes to IItemList, but this will be handled in a separate issue.

I know most just skip over this, but this is kind of a huge thing to be discussed for the future of AE2. Personally, even if it takes a long time to finish, I support the move to how 1.13 works. Would you be able to use ae:densecable_green as a means of doing the labelling? I know that might add difficulty..

Hi AE2 devs,

My view on the subject is: when a user selects an item (either for a crafting recipe or a filter) they should be able to chose which tag (if any) will be used.
For instance, they put an item, and then middle click on it (or something else) to open a small GUI to choose the tag for this item.

Such a GUI could also be used to ignore damage/NBT.

I don't know how difficult it might be to adapt AE2 code, but for the user side, I have the impression it is as simple as it could get while providing a huge flexibility.

What do you think?

ATM it looks like forge will drop oredict. But they want to provide and additional system to tags to define equivalent items for unification of eg ores, ingots, gears etc. This is different from the often miss used oredict and the new tags. Its "can be used as" (oredict, tags used in recipes) vs "is equivalent to" (conversion from one instance to another)