Investigation of a panic upon entering light memory pressure (causing inactive page scan) in an environment where QUEUE_MACRO_DEBUG_TRASH is enabled by default exposed an issue in vm_pageout_collect_batch().
The while loop iterates over the pages in the pagequeue provided, but when dequeue is enabled [as for inactive] the next pointer is technically invalid. This is hidden without the DEBUG option lit as the stale pointers are kept and the pagequeue lock should keep the next element on the list, but with the DEBUG option setting the pointers to -1, a panic ensues.
I would also argue that programatically, relying on the now-stale next pointer is effectively relying on the TAILQ implementation details (it could move to an underlying data structure which could pack elements or other methods where the original pointer could be freed) and should be avoided.