Referring to the MSVBA Language Specification v1.02 (dated 4/30/2014), the WITH statement creates a block. Given the way that blocks work in VBA, it implies that the object named by the WITH keyword is open for the duration of the WITH/END WITH range (i.e. the block). If there is a nested WITH/END WITH block, then the outer object is also available to the inner objects - though if there is an overlap in property names between the two, disambiguation would be required.
My idea here is a surmise, a hypothesis, but not a provable fact BECAUSE Microsoft does not publish that code for us to examine and thus answer. However, there is this concept called "active references" that is how Windows (and therefore Access) know that something is still busy. This "active reference" concept is why two people can both open a shared back-end through their private FE. One can do a SELECT and the other can, milliseconds later, do a DELETE of the same record, and yet the recordset for the SELECT doesn't go away instantly. Its "active references" count isn't zero so it has to wait until the recordset is closed or the auto-requery timer expires. It is also why you can read a shared file that you opened before someone else tried to delete it. It is also why you can't delete an open file like the .LDB or .LACCDB file.
Using the WITH CurrentDB.CreateQueryDefs clause, and because there was an implied reference action in the WITH clause, the "active references" count isn't zero inside the WITH block. Therefore the object properties referenced under the WITH clause remain viable. However, issuing an explicit 2nd CurrentDB reference such as CurrentDB.RecordsAffected (thus stepping outside the implications of the WITH clause) forces a re-evaluation of CurrentDB and that re-evaluation resets things like the .RecordsAffected property.
It would be an interesting exercise to test whether making a reference to .RecordsAffected would be dual-valued. Create an WITH block based on a DAO database variable that is a copy of CurrentDB. Do an .Execute of some action query, then assign a variable from CurrentDB.RecordsAffected, then assign a different variable from .RecordsAffected (with no prefix and still inside the WITH). Would they report different numbers, specifically with the SECOND reference that uses the WITH clause having a non-zero value? According to the VBA language reference, the explicitly qualified reference would be a different reference than the reference inside the WITH block. I'm working on another project at the moment but might get around to trying this unless someone beats me to it.
