I had AI do a deep inspection and analysis of 6.4 Beta 8 regarding the issue affecting images either getting duplicated or not moving at all in the History. It got really technical and went deep into the nitty gritty details of several issues it identified, but below is the more high-level and human-readable summary of the analysis and resolution that I asked it to produce at the end:
Selecting an image in History does not move that row. The click loads the stored image, puts it on the clipboard, and pastes it. The row only moves if the clipboard watcher later decides the clipboard still holds that same History item. For images that check usually fails, so a second copy is added at the top and the original stays where it was. Text goes through the same path and moves correctly, because its identity is a hash of the exact string.
Image identity is an MD5 of a freshly built 32-bit device-independent bitmap (DIB), header included. That hash was taken from the original clipboard bitmap, then the picture was saved as JPEG (PNG only if that option is on, and it defaults off). On selection the file is decoded and that decoded bitmap is what gets published. The watcher hashes it again, and assigning the image always recomputes the hash, so the one stored with the row is discarded. JPEG output does not match, and neither does a lot of PNG output: a normal clipboard DIB often has 0 in the unused alpha byte, while a GDI+ reload comes back 24-bit or 32-bit with alpha 255. Those look the same and hash differently. Any 32-bit alpha, red, green, blue (ARGB) format is also treated as transparent, so the republished image offers PNG and DIB version 5 (DIBv5) instead of the CF_DIB clipboard format.
The watcher is debounced, about 150 ms, and every clipboard update restarts the timer, so it reads the clipboard after the paste rather than the data just published. A lot of apps replace an image on paste with their own encoding, which does not carry the "this came from a History item" marker. If the original item also had text or a file list, those have to match too, so an image-only echo misses even sooner.
Sometimes an older image neither moves nor duplicates. The History window closes and focus returns before the image is published, and the target opens the clipboard for the paste. If the clipboard is still open, the watcher retries up to 10 times and then drops the update. An image paste often holds it open that long, and closing it after a read does not raise another notification. The update is also dropped when the read produces no usable bitmap (decode failure, or over the 20 MB capture limit) or when that app's capture rules ignore images. The other silent case is a read of the previous clipboard contents: matching walks from the newest row and uses the hash, not the row that was clicked, so it re-stamps the item already at the top and leaves the one you selected alone.
The click should move that row by its id as soon as it is chosen, and write the new timestamp then. A later failed read, an empty read, a size-limit skip, or an ignore-application rule must not undo it. Those rules are for new copies made by other programs. They should not apply to a row the user just chose. Put the same id in a private clipboard format on the data object you already mark as "placed from History." While that format is still present, the watcher should move that id and skip the image-hash path entirely. Reading your own bitmap back and hashing the clone is what drops the stored hash.
That marker is often gone by the time the debounced read runs, because the target has replaced the clipboard. Remember the id, and a canonical copy of the image, from the moment you publish until the next real copy that did not come from History. Image paste raises several updates (the initial publish, format synthesis, then the target's write), and the timer restarts on each one, so the read you act on is usually the target's later write. One "ignore next change" flag gets consumed by the first of those. While that remembered paste is still in effect, a new clipboard image that canonically matches the image you just pasted should update that same row. Canonical means straight-alpha pixels, with alpha forced to opaque when no pixel has partial transparency, and no DIB header bytes in the hash. Do not also require the original text or file list to still be there, since the target often puts back the picture alone. If the read still shows the previous clipboard item, leave that top row alone instead of treating it as the thing the user selected.
For ordinary copies, keep content dedup, but hash the same canonical pixels you will compare later, after the encode and decode you actually store. JPEG cannot be the identity. Persisting PNG is the straightforward fix. Hashing the canonical decoded pixels once and storing that hash also works. Checking "transparent" from the pixel format should be replaced with a check for partial alpha, so an opaque 32-bit image is published as CF_DIB again and the round trip stops changing shape. The open-clipboard retry can stay as a way to get a clean read, but the id-based move has to stand even when those retries run out.
