What a general-purpose API gains in uniformity, it loses in specificity. A general-purpose, one-size-fits-all implementation needs to be generic enough to be applicable for the majority of RTOSes. This leads to the unique portions being left out of the standardized interface, which can sometimes include some very interesting features.

Since the RTOS vendors themselves aren't always the ones providing support for CMSIS-RTOS, there is the potential that the version of CMSIS-RTOS being shipped is lagging behind the RTOS release cycle. This means that RTOS updates to CMSIS-RTOS might not be included as often as for the native API.

There is also the problem of obtaining support if problems are encountered – an RTOS vendor will generally be more willing (and capable) to help with code they actually provided. Often, it will be very difficult to get support for an abstraction that the RTOS vendor hasn't written – both because they are likely to be unfamiliar with it and the abstraction itself can contain bugs/functionality that isn't present in the base RTOS code.

Now that we have a general idea of what a general-purpose RTOS API is, let's take a closer look and compare the FreeRTOS and CMSIS-RTOS APIs.