Ahead of ABI Stability, decide if vtables are ABI and lock it down if so.
Invoking a non-final instance method involves calling a function that is not known at compile time: it must be resolved at run time. This is solved through the use of a vtable, or virtual method table (so called because overridable methods are also known as "virtual" methods). A vtable is a table of function pointers to a class or subclass's implementation of overridable methods. If the vtable is determined to be part of ABI, it needs a layout algorithm that also provides flexibility for library evolution.
Alternatively, we may decide to perform inter-module calls through opaque thunks, or compiler-created intermediary functions, which then perform either direct or vtable dispatch as needed. This enables greater library evolution without breaking binary compatibility by allowing internal class hierarchies to change. This would also unify non-final method dispatch between open and non-open classes while still allowing for aggressive compiler optimizations like de-virtualization for non-open classes. This approach would make vtables not be ABI, as that part of the type metadata would effectively be opaque to another module.