Which is a type of objects in mainstream OO languages: a class, an interface, an abstract class, a metaclass?
Unfortunately I don't have a copy of TAPL with me, so I can't figure out exactly what the author intends. But there is a point we should make, that types are something which classifies terms or values, even if there are other pieces that are related to the type.

As such, classes and interfaces are not literally types themselves in Java or C++. Rather, each instance of a class/interface defines a few things simultaneously:


At runtime, we associate with each such defined class, a table of details. This can include where to find code for overrideable methods, but also information like which methods exist, what fields and the like, for reflection.
Both at compile time, and runtime, it defines a type with the same name, which denotes those objects whose runtime class is a subclass of said class.
So here we have a distinction we can make: Each object has exactly one class, but belongs to potentially many different types (the transitive reflexive closure of the subtyping relation).


This is different from the situation in something like OCaml, or likely, those simple objects in TAPL. If there is no means of distinguishing which class created an object, we likely do not want to associate it with a type (as we cannot do anything different with it). In particular, classes in OCaml define a means of constructing an object, so they are a value (just as in the function x -> x + 2).

Following this reasoning, we can think about what metaclasses imply for Python. When we define a metaclass, it creates a particular object, much the same as any other Python object. This portion is a value. Now, later code may reference that value for construction of classes. As stated, we haven't quite made them relate to types yet.

And from here, the answer really comes down to what we decide the types are. It is reasonable to say that objects have a type based on their class (Note again, this is distinct from the denotation given by the type function in Python, which returns a value related to our type). In this situation, yes, metaclasses can be considered to define a kind, as to each class-type, we have an associated metaclass. But we'd be just as reasonable to not consider anything here to be types, and to work only with values and functions.

To really talk about this, we might want to say that Python has a reflection principle: for every class value, we have an associated class type, and vice versa. Extending this we can talk about metaclasses as kinds, (but that will begin requiring subkinding, which may be undesirably complex).

So the key point of distinction we come down to is this: types are classifications, and values are concrete data structures. There can certainly be relations in languages which have run-time type information, but they are not literally identical, and there may be multiple sorts of things defined simultaneously.