If you notice I mention shortly after in the article that the dummy attribute approach leveraged the engine's built in abilities to know which bits of the current operation need to be cloned. This is primarily why I went with this way. Despite it looking a little less legible, I figured it might be more future-proof.
Your approach would look something like this.
<description>Convert add to direct add + empty modify trigger</description>
<comment xml:space="preserve">Add a cloned/empty modify event (inherits all attributes and operation data from add)
Convert the the add event to a direct add (so it will write directly to the destination system)
Schedule this rule immediately prior to the Toolkit Rule: "Generic validated direct-write".
Once the add event has been written directly, the empty modify event can then be used in subsequent policies to trigger any actions which might require the object to already exist in destination system.</comment>
<do-append-xml-element expression=".." name="modify"/>
<do-clone-xpath dest-expression="../modify[last()]" src-expression="@class-name|@dest-dn|@dest-entry-id|@event-id|@qualified-src-dn|@src-dn|@src-entry-id|association|operation-data"/>
<do-set-xml-attr expression="." name="direct">