To your first question: Another possible reason why volumes listed as Available won't be used is if they have exceeded their configured maximum number of mounts or if they were assigned an expiration date. If either of those occur, the normal NBU interfaces won't bring that to your attention and EMM will simply not use those volumes for writing. I always reccommend to my students that they alter the columns of the Media section in the Windows/Java consoles to show both current and max mounts and to keep an eye on those numbers. The available_media script does not show mount numbers.
To your second question: It seems like there might be something else on that formerly frozen tape. When NBU mounts it, it finds whatever that something else is (non-NBU formatting, mis-matched Media ID, etc), and freezes the tape without writing anything on it. I suspect the cleanup process notices that there are no valid images on that otherwise assigned piece of media and deassigns it, and if it was originally in the Scratch Pool before use, it would be moved back there. Your Job Details for the job that froze the tape should give you a reason why that was frozen, or check your media logs report.
It has a different Media ID pattern than the other volumes you've listed, suggesting a different barcode pattern, suggesting it was not added to your environment at the same time as the other tapes. What's the history behind that tape? Was is used somewhere else before winding up in your library? If there isn't anything on that tape that you care about, I'd run a Label job on that volume (Media section, find that volume, right-click and choose Label, make sure you UN-CHECK the check-tape-before-labeling safety box or the label process will be aborted if there IS something on the tape that NBU won't normally overwrite)
