When we talk about compatibility to a standards like W3C, we simply align on the overarching idea, how data is being modeled and key concepts. In the standards, there is no guidelines on implementation of the verification algorithm while some are provided. For that reason, multiple implementation of W3C VC will be present. Examples are uPort, Evernym, Credly, etc (see https://w3c.github.io/vc-test-suite/implementations/).
To implement W3C standards is like a printer manufacturer implementing USB cable for their data cables. For the printing company, implementing USB (according to the standards) alone does not allow for the printer to be used universally across all devices. By usage we talk about actually printing, not powering it up.
The same way if we implement W3C standards, it does not mean other verifiers will be able to verify our document.
In the printer manufacturer's example what is clearly missing is the printer driver for the major OS'es. With a compatible printer driver, we can now allow our computers to send print jobs to the printer. That printer driver is the custom verification module that extends USB. The same as how the OA verifier will extend VC (see https://w3c-ccg.github.io/vc-extension-registry/). Without installing this driver, it will not be possible for a machine to know how to send a job to the printer even though it has an USB port.
Or does it?
The concept of a universal verifier is similar to having an OS that either has all the printer driver of all the printer or knows how to find the driver when it is missing. In the first case, the universal verifier will simply implement all types of verifier (risk of using wrong driver for printer) or have a specifications on how to search and which registry to search (oh, another standards here.)
Finally, even if you are able to print a piece of paper, does it mean that the recipient knows how to interpret what's being printed? That's not a job of a printer to specify which language or color your document should be in. The same way as how the document framework should not be aware of the data schema. That's for the sending and receiving party to agree upon. There's really no point in sending an English reader an Egyptian text does it? But is it the printer manufacturer job to enforce it?
USB ↔ W3C VC
Printer Driver ↔ Custom verification module
Schema ↔ Language or format of printed material