The PDB function 'gimp-image-select-item' does not respect the changes made to a path that has been transformed using 'gimp-vectors-stroke-scale', 'gimp-vectors-stroke-rotate', 'gimp-vectors-stroke-translate', et cetera. 

To verify this anomalous behavior, perform the following steps in the Script-fu console to create a new image with a square path:

(define image (car (gimp-image-new 100 100 RGB)))
(gimp-display-new image)
(define layer (car (gimp-layer-new image 100 100 0 "BG" 100 0)))
(gimp-drawable-fill layer WHITE-FILL)
(gimp-image-insert-layer image layer 0 0)
(define path (car (gimp-vectors-new image "Path")))
(gimp-image-add-vectors image path 0)
(define stroke (car (gimp-vectors-stroke-new-from-points 
                        path 
                        0 ; type bezier
                        24 ; number of coordinates
                        #(10 10 10 10 10 10 
                          20 10 20 10 20 10
                          20 20 20 20 20 20
                          10 20 10 20 10 20) 
                        TRUE )))
(gimp-item-set-visible path TRUE)
(gimp-vectors-stroke-get-points path stroke)
---END OF CODE---

At this point, everything is fine. Now let's perform some transformations on our square path:

(gimp-vectors-stroke-scale path stroke 4 4)
(gimp-vectors-stroke-get-points path stroke)
---END OF CODE---

Even though there is no update to the display, we can see that the points in the path have been properly transformed. And, as expected, further transformations will be based on the new coordinates.

(gimp-vectors-stroke-rotate path stroke 60 60 45)
(gimp-vectors-stroke-get-points path stroke)
---END OF CODE---

We can even stroke the path and it is properly painted: 

(gimp-edit-stroke-vectors layer path)
---END OF CODE---

The problem arises when we try to create a selection based upon the transformed path:

(gimp-image-select-item image CHANNEL-OP-REPLACE path)
---END OF CODE---

Our selection is not based upon the transformed points of our path, but is instead based upon the original, unscaled and non-rotated path (the one displayed in the un-updated display). I can think of no reason why this behavior should be desirable, and thus this bug report.

I have tried flushing the displays, toggling the visibility of the path, even making another path active then switching back; all to no avail. 

There is a work-around, however, that reduces this bug to being almost trivial. If we add or remove a stroke on the same path after it has been transformed, the path will be fully updated -- it will display properly if visible and selections can be properly created from it. 

The following code adds then removes a simple, one-point stroke to induce this update:

(gimp-vectors-remove-stroke 
    path 
    (car (gimp-vectors-stroke-new-from-points 
             path 0 6 #(0 0 0 0 0 0) FALSE )))
---END OF CODE---

With this work-around, there is probably little pressing need to resolve this bug. Nonetheless, it seems strange that just the one function, 'gimp-image-select-item', does not honor path transformations. More concerning than the unintuitive nature of the work-around is the thought that 'gimp-image-select-item' might be accessing memory that has been freed or only maintained within the UNDO history (which might eventually be freed. Why else would the original path points still exist in memory?

As a final note, while I have posted this under the Script-fu component, I would expect that the bug report applies equally to plugs-ins (as it is only using PDB functionality).