A "technically pure" JDO implementation, as you put it, would rely on JVM-level hooks into the transient object lifecycle which could be used to trigger corresponding events in a persistent object cache.
When JDO was being scoped such design choices were discussed with the JVM team. The upshot was two-fold:
1. In the timeframe for releasing JDO, the JVM would not be changed to provide these hooks.
2. Implementing a custom JVM, which all JDO-based application would then be forced to use, would make JDO "undesirable".
These were the basis for the current model with its PersistenceCapable interface.
However, do bear the following in mind.... Neither the application objects (which invoke PersistenceManager services) nor the domain objects (which are persistence-capable) actually depend upon the PersistenceCapable interface. If you are coding against the PersistenceCapable interface then you are doing it wrong (or you're a vendor writing a JDO implementation). That's why PersistenceCapable is in the JDO SPI (javax.jdo.spi) and not the JDO API (javax.jdo).
This means it is conceivable that, with sufficient direct support from some future JVM, the underpinning mechanism of JDO's transparent persistence could be changed. (There are no plans for this in hand, I'm merely hypothesizing about some futuristic environment.) At that point the current requirement for "bytecode mutilation", as you so objectively term, it would be removed. However, your application and domain object source code would not need to be altered to function correctly in this new environment.
My point? PersistenceCapable, and the requirement for domain objects to implement it, is an implementation detail of the current internal JDO architecture, and is - at least conceivably - subject to change. Good encapsulation, as exhibited by JDO's external architecture, insulates your classes from any dependency on this implementation detail.
Kind regards, Robin.
Robin M. Roos