I haven't done embedded systems work in a long time (even though I was fairly good at it), because it can be pretty hellish compared to working on web/desktop environments: it's like developing on a quicksand because the hardware initially is unstable, the software platform is unstable, the tools are generally crude compared to Eclipse and Visual Studio, and of course your own code can be unstable, especially with most microcontrollers w/o an MMU where you can overwrite memory or stacks easily. Embedded projects using an MMU (e.g. ARM Cortex A8) running embedded linux with lightweight threads feels like developing on a Linux machine and are far easier to work in.

My list of things to look for in a productive RTOS:
- low-power sleep mode APIs...grafting this on later is a huge PITA; and you do have to wonder about RTOS companies that have said they've been in the business for over 10 years (e.g., smxRTOS) who haven't implemented any APIs for lower-power modes
- plug&play (deactivate/re-init) any devices (including CF cards which are handled as IDE drives) because you'll need to power peripherals down to save power during deep sleep and turn them on when you go back to full speed
- debugger support for threads and thread stacks...being able to stop the system and examine all the threads is essential in multithreaded development; most RTOS systems use an internal multitasking engine and tools like gdb need a layer over them to be able to read into these internal structures
- profiling support so you can tell when threads are active and where the CPU hot spots are...profiling is essential for any high performance application, but is arguably more important when you're trying to maximize low power sleep time
- a networking (TCP/IP and PPP/SLIP) layer that doesn't suck...networking is essential with the Internet of Things and if your networking layer has problems routing or can't shut off PPP when it's idle for a while, it'll cost you a lot more to operate
- the ability to detect stack overflows, hitting file descriptor limits, file handle leaks, etc. is essential to embedded development of devices that are on all the time and to know when you're about to trample memory
- USB OTG (to plug in mass storage or networking adapters) and USB Device (to act as a serial port) is essential for field debug and expandability
- reliable FAT file system support for flash cards...getting the size and free space can be realllly slow with crappy FAT drivers
- reliable wear-leveling file system for internal flash because it's always easier to talk to internal memory as files
- easy to use interrupt handling (preferably with C++ support)
- source code so you can fix things in case the vendor doesn't fix things fast enough....and most importantly, this source code has to be able to compile cleanly

We're using eCOS and it fails most of these requirements :-P