This paper, says
The current implementation of queryable state supports point lookups of values by key. The query client asks the Flink master (JobManager) for the location of the operator instance holding the state partition for the queried key. The client then sends a request to the respective TaskManager, which retrieves the value that is currently held for that key from the state backend. From a traditional database isolation-level viewpoint, the queries access uncommitted state, thus following the read-uncommitted isolation level. As future work, we plan to add read-committed isolation support by letting TaskManagers hold onto the state of committed snapshots, and use that state to answer adhoc queries.
Whether the state querying following with read-committed isolation level has been implemented in the latest version Flink.
No, this has not changed. With queryable state you are accessing whatever the state happens to be at the time the query is processed.
This means that, for an example, a subsequent recovery might effectively rollback the state to an earlier value.