It would seem that Mojang's new model for a potion is simply a list of effects registered dynamically to a key. The concept of extended and tiered potions is implicit in the recipes, but not hard-coded anywhere. This makes sense, as mods will presumably want to customize the brewing tree.

If we're replacing the potion API now, we should at least try to design something that is forward compatible with the registry model. We know PotionData has no chance of that, since it depends on a static enum of potion types, and the extend/upgrade brewing tree.

SportBukkit's potion API has a PotionBrew interface that wraps nms.PotionRegistry and transforms the list of NMS effects. Instances come only from the registry, by looking up a string key. PotionType can be used to generate the known keys, but nothing depends on PotionType.

We exposed the "minecraft:*" keys directly, because we need something we can parse from XML files. However, the Bukkit API would not necessarily need to support string keys. It could use PotionData as a key, and add support for string keys later without breaking anything.

I am willing to work on this if we think it's a good idea.

FYI:
https://github.com/OvercastNetwork/SportBukkit/blob/beta/Bukkit/0066-Modernize-potion-API.patch