Bridge 5 operational bug?

Question

BACKGROUND:  I have reconstructed the file arrangement of my 8 tera-byte, 630,00 image photographic archive.  All directories had BridgeCache files fully created.  The two master caches (to address the 500,000 image "limit") were constructed on an external esata/usb drive.  The option choses for the "Build Cache for Folders" had the "Export Cache to Folders" disabled under the assumption that it was not necessary since the master cache was being rebuilt from the folder BridgeCache files.   The reconstruction was done on a laptop running Bridge 5 under the Win XP operating system.  This multiple week operation completed successfully and the generated master casche systems work on both the WinXP lap-top as well as my main Win7 64bit workstation - with one excpetion.  This exception (I think) is a bug in Bridge.
DESCRIPTION of OPERATION:  I invoke Bridge in multiple ways.
1. Start bridge initiated from the desk-top icon.
2. Start bridge by drag-and-drop of the .BridgeCacheT file onto the desk-top icon.
3. Start bridge by double clicking on the .BridgeCacheT file (associated with Bridge5)
4. Start bridge by drag-and-drop of an image file onto the desk-top icon.
5. Start bridge from another programme using the Win API function "ShellExecute" using the Bridge.exe path name and a path to a selected image (or .BridgeCachet) file as arguments.
6. Start bridge from the Command Prompt using the Bridge.exe path name and a path to a selected image  (or .BridgeCachet) file as arguments.
If Bridge is started using 1,2,3 or 4 above, the operation is as expected for all rebuilt directories - thumbs are shown "very fast" and are properly constructed with whatever crop and other correction was made in Adobe Camera Raw.  This action is noted on both the Win7 workstation as well as the WinXP laptop.
If bridge is started by method 5 or 6, the operation is varied but identical on both computers.  If I access a directory that was created AFTER the cache rebuild described above (i.e. a new photography project), operation is fast and works rapidly with all thumbs and preview images being displayed properly.
If I access a directory (using 5 or 6) that was created by by the rebuild but has not yet been re-processed the following is noted:
a. The Build Criteria stage of Bridge takes a long time searching all files in the directory.
b. Thumnail and preview extraction start immediately after the Build Criteria stage is completed  (in spite of having the images already an properly in the master cache and in the .BridgeCache file);  Initial thumb display seems to be embedded thumbs in the image file - which is "fixed" during the processing.
Both of the above are very noticeable when I view the network activity with Windows Task Manager.
If I terminate Bridge at this point with the caches not reconstructed, I can restart Bridge by methods 1, 2, 3, or 4 above and the fully built thumbs and preview images are "instantly" available.  If I then restart Bridge using methods 5 or 6 above, the thumb/preview images rebuild takes place again - from where it left off in the previous attempt.
If I allow this rebuild for the directory to go to completion, I can restart bridge by any of the above 6 methods and the "reconstructed" images are immediately available.  The only network activity noted is a very low level doing what I assume to be a consistency/currency check for "unexpected" image file changes.
Browsing the master cache 256 and 1024 directories with the FastStone viewer before and after the rebuild yield no identifiable changes to the thumb nor preview files.
THE BUG:  It seems that, if bridge is started from the command prompt or by another programme, it may reprocess the images in a directory unexpectedly - in spite of the fact that starting bridge with normal desk-top icon or drag and drop do not cause the directory to be reprocessed.
My assumption is that ANY of the above 6 methods of invoking Bridge 5 SHOULD BE identical in operation.
I also notice that, if I start Bridge with the WinAPI ShellExecute function with ONLY the path the Bridge.exe (no file is specified), Bridge will start cleanly without an attempt to build any thumb/preview images.
It seems to me that the problem is associated with having a file name passed as an argument when using the Command Prompt or the WinAPI functions.
Thank you,
tony

Answer 1

It really would be nice if Adobe could provide a "fixit tool" that would update the cache structure to flag the various constructed cache directories as current and up to date in such a way that a rebuild and data duplication would not be done.  This would go a long way to making cache rebuilds from the .BridgeCache files a useful tool.
P.S.  This file processing problem did not happen when CS5 was released and I migrated from Bridge CS4 to CS5.  Hopefully a fix can be provided.