theory... btd0: driver called differently with .NET CF 3.5
Thanks very much Laurie for that information. I think we can all respect Celio's support policy, but providing extra information like this is extremely helpful to power-users and can only increase goodwill. It may also lead to information that helps your developers.
(I am a law student and the recent owner of a slightly-used C8. My iPAQ 910c was slow with the stock ROM and so I learned how to cook a custom ROM for it - the first one ever made for that device, actually. So it is a priority for me to make the ROM fully compatible with the Redfly.)
After searching a bit about this, it seems that certain driver calls may behave differently under .NET CF 3.5 compared to 2.0. Thus my current theory is that the Redfly Bluetooth functionality is incompatible with .NET CF 3.5.
The theory makes a lot of sense based on user experience. All official manufacturer WM6.1 (and previous) ROMs come with .NET CF 2.0. However, *most* cooked ROMs are cooked with .NET CF 3.5 instead, because it is thought to improve application speed. However, a few ROM chefs out there just keep the original .NETCF from whatever stock ROM they have ported.
I'm travelling right now so I won't be able to test and confirm the theory until later this month. However, there may be a way for users with .NETCF3.5 cooked ROMs to install .NETCF2.0 from cab and get the Bluetooth feature working.
Of course, I expect this will be resolved anyway when Celio releases drivers that are WM6.5 compatible - as I understand that even "official" stock WM6.5 ROMs will come with .NET CF 3.5
EDIT: bad news, it looks like you can only install *newer* .NET CF versions ontop of others. I now predict that only ROMs with .NETCF2.0 (or earlier) cooked into them will work with Redfly over Bluetooth. Easy enough for we ROM cooks to fix for ourselves; good luck getting other chefs who don't own Redfly to release editions with the older .NET CF