I think this is incorrect, the point of Guile-Emacs is to implement support for all Emacs Lisp in Guile. No backwards-incompatibility will be present in whatever Emacs eventually moves to.
One example is that some extensions such as Gnus have contain code written in the current Elisp interpreter's bytecode, which is incompatible with the Guile VM.
Your question is invalid, so answering it is impossible, but it is a very normal mistake to make, so you have no reason to feel bad about it.
Common Lisp is a language, while what they are integrating to Emacs isn't a language, it is a VM used by an implementation of a language. The VM itself is generic enough to be compatible with Elisp (although I believe there was some struggle to deal with the differing way nil and #t work between Elisp and the Guile VM).
It is a bit like how both Java and Ruby can run on the JVM, Java being born with it and Ruby being ported to it through JRuby.
A particular implementation of Common Lisp can have a VM that is similarly compatible with Emacs, although all GNU Common Lisp implementations are not as actively maintained as Guile is.
On the language side, Common Lisp is definitely incompatible with Elisp, as they have differing semantics. Historically, Common Lisp has had lexical binding, while Elisp has dynamic binding. (From Emacs 24 on, one can turn on lexical binding on a file by file basis.) Elisp also doesn't have closures. Finally, the numeric tower is different between the two.
Common Lisp implementation also tend to not use VMs too much nowadays. GNU CLISP has a VM. ABCL runs on top of the JVM. CMUCL can run on a VM. But that's mostly it. The rest uses native code, either directly or via C.
