The expiration on the “in progress” message is exactly 24 hours, so if something goes wrong with the background optimization, and it doesn’t complete, it will not change for at least 24 hours. To see if stuff is stuck in the queue, you’ll need to check that queue debugging page (which it probably is). Otherwise, when EWWW finishes optimizing an image, it removes the “in progress” message and allows the display of the compression results. If anything interferes with the background processing, or you import lots of images at once, it is entirely possible for images to be stuck in that state until the cache expires (again, 24 hours minimum).
As to the latter, the real optimization results have always been stored in the ewwwio_images table, but the media library list view pulled the optimization messages from the attachment metadata. In 3.2, the plugin moved away from any usage of the attachment metadata, so that’s probably why you’re seeing a difference there all of a sudden. Normally, the switchover is pretty seamless, but if the plugin is having trouble linking the ewwwio_images results to the appropriate attachment ID numbers, you’ll see those sorts of messages for image that are already optimized.
The first thing that comes to mind is if you have ever switched webhosts, or a different server. Something like that would cause the image paths to no longer match the ewwwio_images table, and prevent the linking from working.
You can also enable EWWW’s debugging mode to view the raw attachment metadata, which should still contain the old results messages.
So, let’s focus on issue #1, the “in progress” messages, which could indicate that images aren’t getting processed properly. We’ll come back around to the other once we resolve the in progress stuff. Check that queue page and see what you find.