This question is more about language design and less about changing C++ conventions.
While thinking about the Go programming language (how it cleaning separates the data from the interfaces, effectively turning all objects into structs) and PODs in C++ (I like memset/memcpy when allocating a gazillion small struct-like objects), I was wondering about the C++ compiler convention of attaching a vptr directly to an instance of an object, messing up the layout.
Is this a requirement or just a convention?
If you were designing an alternative compiler, could you, instead, have a large external look-up table for vptrs? For example, a structure like map<void*,vptr>? All instances would be POD, with respect to memory setting, and to look up its vptr, we would take its address and look inside the large external lookup table.
The disadvantage is, everything would require a lookup. Is this a viable alternative design or are there serious drawbacks?
Performance will very probably suffer. Some languages add some kind of caching for method lookup.
You could have a different way of finding the method to call for a given selector (or method name). Look at Smalltalk or Self or Javascript or Common Lisp Object system or Ocaml
However, some languages implementation contains clever tricks (caching, JIT, …) making them as fast as C++ (but it is an implementation issue, not a language design issue).