When I've confirmed the implementation I'm following is the right one, I could remove these and replace them with direct types. This makes the code significantly easier to maintain however, and I'm already glad I did it. (tag_list was a vector in the original plan, and works more effectively as a set).

I'm generally a proponent of having code defined in only one place, and typedefs seem to the most effective way to do that here. Everything that uses these knows it's the same as everything else, while using the type directly means each one would have to be updated individually.

But yeah, if you want this removed later after the design has become a lot more concrete, that's an option. At the very least, abstractions like itype -> item_template can removed. But I think it's important, especially during to development, to differentiate between what an object's type relationship is locally (the things that must be the same, and that will continue to be the same even if they are the same something else) and what external type it happens to be implementing at the moment.

Here, in particular, I haven't yet decided if I want to reimplement the itype class (there are some clear potential benefits, but it's not simple), so for the moment I'm leaving that option open.