Well, well, well. Apparently delayed block cleanout doesn’t happen during a direct path read. Which makes a lot of sense, if several folks are doing direct path reads at the same time on the same object, then how do you control the updates to the blocks? In case you don't know, a driect path read is done into the PGA (Program Global Area) which is basically private space to your process. No one else knows you have those blocks. So if two (or more) folks are reading the same block at the same time into their own PGA, then each one could make a change to the block at the same time and really mess things up. Kind of blows up the entire read consistency and locking model.
What is quite interesting to me is that on windows it’s not doing direct path and on UNIX it is. So the blocks do get cleaned out on windows BUT not on UNIX. Not my test is at least unlikely to happen frequently in “real life”.
My test was simple: Create a big table. Select from it. Delete it all. Commit. Select from it again. Select from it another time.
In 11 and earlier, you’d see the clean outs happen on the first select after the delete, and then not on the next. But starting in 12 (on UNIX), you’d see the clean out every time after the delete. Because it's always doing direct path reads, hence it has to clean out the blocks each time it reads them in. It's cleaning out the locks and such left over from the delete, since most of the blocks are not cleaned out at the time of the commit. The commit does clean out some of them. But this table is big enough that there is no way it can get to all of them.
On windows the behavior was like it was in 11. It's not doing direct path it's doing "normal" reads in to the buffer cache.
So change in the game for how reads are done in 12.