I don't recall encountering this before & I don't see it documented.  

Within a process that has updated, but not committed, a record & its index, that same process encounters the public old index value, not that in the the cached not-yet-committed record.

Some pseudo-code:

1. BEGIN TRANSACTION
2.    create or update a record that has an indexed attribute that is changed
3.    CALL  subroutine (or inline)
       3.1 direct read of record updated in step 2.  - The new version is correctly read.
       3.2 selectindex to find the rec from step 2.   - Performs as if the old value is still indexed.
       3.3. EXECUTE 'SELECT ...'  functionally same as 3.2, using the index.  - Performs as if the old value is still indexed
       3.4. EXECUTE 'SELECT ... NO.INDEX'   same syntax as 3.3 but NO.INDEX - Performs finding new value
       3.5  return
4.    COMMIT
5.  END TRANSACTION

(The above is all within one process, one basic program, inside one transaction.  Not something executed by competing independent processes or users.)

Step 3.1 correctly reads the new version of the uncommitted record as cached to overarching transaction
Step 3.2 & 3.3 is evaluated based on the public old version of the transaction, not the cached version and its new indexed value.
Step 3.4 is evaluated based on uncommitted cached version of the record.

I think 3.1 & 3.4 perform as I expected, as advertised.
But 3.2 & 3.3 look wrong.  I don't see anything in the documentation that says they should misbehave.  

I believe that indexes are updated in a hidden transaction within a write to the primary record to be indexed.
I thought that should this would be initiated as the basic WRITE command is encountered,  but it appears as tho it does not begin until during the COMMIT, when the actual write occurs.   I do understand that locking an index for a prolonged period could be harmful to system performance & deadlocks.
But I don't recall encountering this before & I don't see it documented.

The basic user manual says LIST can be EXECUTEd within a transaction.  I don't see any caveats about indexes.

This is UV11.4.
uvconfig has ISOMODE 1.   
I tried a variety of BEGIN TRANSACTION ISOLATION LEVEL {0,1,2,3,4}    grasping at straws.

A bug?  A documentation failure?  Just me?

------------------------------
Chuck Stevenson
DBA / SW Developer
Pomeroy
US
------------------------------