Description Converting to full text no matter what format is selected.

Thanks for the report. Yes, this is a known issue with the last packaged release and was fixed in HEAD and both development branches. The next release will, of course, have the fix as well.
In the interim, please try the current 6.x-1.x-dev (which is quite stable BTW) and report back whether the problem remains.

The field will use whatever filter is set to apply when the form is submitted so if you've got it set to 'Full Text' (ie. all html allowed) it should honour that. If it appears to be 'sticking' with a previous setting, try clearing the cache first before setting it again. You can do this from the 'Performance' page under 'Site Configuration'. In any case, please try this and let me know if that fixes it.

Okay, I'll leave this open and look into it further.

In the meantime you can get around this by adding the tags you want to allow by editing the filter itself by going to: Administer>>Site Configuration>>Input Formats and choosing the 'configure' link alongside Filtered HTML item in the list. Then choose the "Configure" tab along the top and look for the text box that says 'allowed HTML tags'.

That was just a workaround but I've just committed a better fix and released it as a new package so please upgrade and check it when you get a chance and let me know if you have any more problems with it.
Also, you may or may not want to revert those filter modifications (depending on your requirements) I suggested once you upgrade to the newest package. Generally tampering with the defaults should be done with a fair amount of caution so as to not open yourself up to any badness.
Thanks for the offer w/regards to testing. I may take you up on that sometime.

It should still display fine on the page itself, though -- you're just talking about the text field on the input form when it's showing what's already been entered, right?
It's pretty harmless but I suppose a little disquieting (and ugly) if you don't know why it does this ("It's not a bug...it's a feature!") I was far more concerned with the description output since that was a bug insofar as it prevented the level of custom styling one would expect from that content area.
Still, I'll reconsider whether this extra filtering is even required and change it if necessary. Thanks again for the feedback!

Oops. I just re-read your post a little more closely and see that it is an issue with output (provided you use & or other special entity chars). Disregard my previous post (most of it anyway). I'll fix this shortly and commit it to the dev branches, though, rather than a full release since it is a bit of a corner case.

As followup I believe I've traced the problems to some unnecessary filtering calls and think I've resolved the output display issues with the latest commits to HEAD and both 5.x and 6.x development branches but they'll take a few hours to appear in the package listings as snapshots are only repackaged twice (once?) per day.
If you feel up to it, I'd appreciate it if you could test over the next day or two and report back your results so I can close this or refine further. Thanks again.