warning: htmlspecialchars() expects parameter 1 to be string, array given in...

I'd like to apologize in advance for any vagueness or ambiguity in this post, to the extent this might even wind up being the wrong issue queue for this issue. I've spent the better part of an entire day (and then some) on this issue before posting, and I found nothing specifically related elsewhere.

Using Drupal core 6.22 and IMCE SWFUpload 6.x-2.1 in an Acquia Drupal installation profile hybrid with all modules updated (nothing exotic, all 'recommended versions' as of 6/25/11) via Drush, I'm receiving the htmlspecialchars() expects ... string warning. Here are some specific observations at this point:

In our project we're dealing specifically with image files. Everything works as advertised batch uploading & displaying the files until we change the sort order of the images assigned to a node. Upon saving the node after changing the file order (drag 'n drop resorting) the warning occurs, but only when displaying images (as opposed to displaying 'generic files' for instance, which doesn't throw the warning).

• Initial image file selection and resorting (prior to saving) doesn't trip the warning.
• Save -> edit -> resort -> throws the warning - but only when displaying images (regardless of the combination of; Imagefield, Imagecache, or original image).
• 'Generic file' image listings (ie; file references, not actual images displayed) don't trigger the warning, even after resorting.
• Reverting the sort order doesn't eliminate the warning.

Two other quick observations:

• I suspect this issue may be related to #1040756, to the extent of the problems addressed there in the nodequeue_1040756_1.patch rolled by slashrsm. Originally I suspected Imagecache along that line. But the warning isn't exclusive to Imagecache image rendering.
• Another 'interesting' issue we've noticed is the 'list' checkbox doesn't seem to be functioning properly, so unlisted images are still displayed. We've had to delete images from nodes to remove them from display.

Last but not least, the main site we're focusing on to address this issue (as a fairly simple working example) is http://609.tammyandbrianre.com/. That's about all I can't think of for now.