The reason I (and others) have said that Extension Devices are easier to implement than other CCD device types is kind of a "bad thing" if you're looking to be a CCD purist.
It's largely because you have greater opportunity to NOT follow the CCD SDK architecture and go off-piste.

CCD has a specific architecture which is (very roughly) a base driver class, coupled with a transport (e.g. TCP, Serial, ...) and a device (or device family) specific protocol (e.g. the language the device speaks).? These classes are dependant upon one another and need to interact in some very specific ways to work properly, such as device instantiation and removal - what does my device do at start-up, how do I clean up after myself, are commands fire and forget, or do we need to maintain a connection, what happens when the connection is broken, and so on.? In the case of a Display, Cable box or AVR, you really need to stay in your lane for this stuff - but it's often not apparent (from the docs/samples) how you're supposed to do that.

As Caleb pointed out - you find your way through a lot of trial and error, which isn't where we want to be as driver developers.

Extension devices are a bit different - because the consuming app (i.e. Crestron Home) doesn't have any understanding of what the driver actually *does*, it's easier (or less improper) to break out of the CCD mould and implement your transport and protocol any way you like, and if you already have that code from a SIMPL#/S+ version, then it's either that, or re-write the older driver code from scratch in a CCD conformant architecture.

Even so, Extension devices have other elements that "normal" drivers don't - such as the UI definition, translation files, and - most likely - a heavier reliance on User Attributes (a CCD way of passing in custom data).? They all come with their own ways to trip you up on your first few outings... or even after a few years!

And before anyone asks - yes - the frustrations and challenges and suggestions on where improvement can/should be made is all reported back to Crestron, directly into the drivers team & product managers.