I'm new to Extension writing VS extensions, and finding information on the subject like untangling 3 balls of yarn. I've read quite a bit on the MSDN site, as well done a lot of failed google searches.
My goal is to write a Visual Studio extension (using MEF and MPF) to improve the support for a language, which was created by a 3rd party. The 3rd party already has a VS extension, which supports debug as well as minimal Intellisense, and provides colorization. I don't want to lose their debug support, but I do want to improve every other aspect of the experience.
From my understanding, a given language (content type) can only be supported by one LanguageService and/or set of Editor services through the MEF (colorizing, intellisense, etc). Is this correct? Is it possible to replace their existing Intellisense, and add other features?
Yes, with a bit of effort you can bypass the registration of their language service and register your own for the same file extensions. The language service is very nearly independent from the debug engine (I say nearly because a couple small things like breakpoint placement at design time passes through some of the language service objects, but it's not very important).
I suggest supplanting their language service with yours completely, which will be a lot simpler than trying to augment theirs without breaking it, especially without having access to their source to make changes.
Most registrations are bound through entries in the registry, e.g. at HKCU\Software\Microsoft\VisualStudio\14.0_Config\. This is not true of MEF components, but MEF components tend to be filtered by content type, which is defined by the language service, so you should be fine as long as you define a different content type in your language service and bind your stuff to that.
You can register your language service for the same file extensions but with a higher priority (via the ProvideEditorExtension attribute on your language service package). Then it's all up to your language service and you don't have to worry about theirs getting in the way (as long as it behaves with content types that are not its own, which it should).
Finally, good luck! Writing a (good) language service from scratch can be a long journey :-)