I ran into a test case where a virtual thread called RawMonitorWait, and a 2nd thread called Thread.interrupt() on the virtual thread. This correctly resulted in the RawMonitorWait returning JVMTI_ERROR_INTERRUPT. However, a subsequent call to GetThreadState returns with the JVMTI_THREAD_STATE_INTERRUPTED bit set. Even so, the JVM does in fact properly consider the thread not to be interrupted. A 2nd call to RawMonitorWait does properly wait rather than immediately return with JVMTI_ERROR_INTERRUPT. This issue does not exist with platform threads.

The issue seems to be that at the java level the virtual thread is still considered to be interrupted even though it is not, and that is what GetThreadState is querying when deciding if the JVMTI_THREAD_STATE_INTERRUPTED bit should be set. See JvmtiEnvBase::get_vthread_state(), which is what GetThreadState uses for virtual threads:

  jint interrupted = java_lang_Thread::interrupted(thread_oop);
    if (interrupted) {
      state |= JVMTI_THREAD_STATE_INTERRUPTED;
    }

So the issue seems to be that when the JVM calls jt->is_interrupted(true) to fetch and clear the interrupt state of the virtual thread, this information is not propagated to the java.lang.Thread instance.

And one more thing to add is that at the java level calling Thread.isInterrupted() does return true for the virtual thread even though it should not.