During the Danish Weekend, we were allowed to upload and run our apps on development devices to see how they work (or what's missing). Turns out that these development units had about the same contents as the SDK (no task switcher, etc..), so some things really could not be tested, and the software environment was not really different from the SDK (apart from running on a real armel machine).

Apart from that: Yes. It's really difficult, and prone to error, and introduces some delays while the package is running through the autobuilder to finally land in the repository and then some more time to get someone with a real device to test it.

Combine this with the fact that the SDK contents differ from the on-device software (this was a big problem with pre-beta2, don't know the current situation), and you're in for some nice trial-and-error testing.

One does get a glimpse of how the engineers of the first moon lander must have felt, having to design and implement something that they can't really test in a real-world scenario before releasing it.

Extras-Devel: I'd say yes. No harm done, and if someone uses Extras-Devel, (s)he has to live with the fact that things might (and will?) break.

Extras-Testing: AFAIK there will be clear guidelines for when a package in -Devel can enter -Testing (and same for the -Testing -> Extras transition), so that apps with problems won't be promoted from -Devel to -Testing without further checks if things work.

Of course, I expect the UI of several Fremantle apps to be redesigned/refined after developers have gotten their hands on a real device and have seen how built-in applications utilize the new widgets and how it works in a real-world scenario. But that's just the UI, and not the backend/lower layer stuff, which can already be stable/ready.

Giving the developers some weeks headstart to fix issues before public availability of the units would be helpful, though.