The plugin interface is MOSTLY a C interface. There are a few COM-compliant C++ bits, but these (by nature of being COM) are basically stable across compilers and C++ versions.
The case where you would see problems for different C++ versions across a plugin boundary is in cases where you’re passing standard library objects from different versions of libc++ across the boundary. So, if you have a plugin interface where the host passes an
std::string from an older libc++ to a plugin built with a newer, you would definitely have a problem if e.g. the internal storage structure of that string has changed.
Off the top of my head, if you were use objects built from code-identical versions of a library (libc++ or otherwise) but compiled with different C++ versions, I think you would still have a guarantee of everything working correctly - but I’m not TOTALLY sure about this. But, to go back to my first point: the SC plugin API does not do this, and indeed basically no plugin API would do this b/c it’s generally considered very bad practice.