>We may someday decide that ATTACH isn't the best way to go when creating mounts

You may be right. However, then the same consideration has to be made with pushing vehicles: Some day we might decide that vehicles should be pushed not via the procedure PUSH and then we need to replace all the checks where the PUSH procedure was checked. In the reply to Matthias' post, I suggested to add an action property for actions with which a mount can be controlled. The same would need to be done for push procedures, no? And seen globally, probably for some more procedures. (E.g. some day we might decide that procedure=DIG will not be digging anymore etc.)
And then, the question arises why it is even possible to check for a procedure if it is that downward incompatible. My reply to that: Well, it isn't downward incompatible - those things will not change just like that.

>No, he doesn't want to check for procedures and ObjectDisabled properties. He wants to check whether the Clonk jumps, regardless of how that may be implemented internally.

I don't deem properties of actions as interna. As much as I don't deem properties of objects as interna (name, id, components, physical values, category and so on...). Taking an item as an example which allows the clonk to jump another time in the air if he is jumping normally (not tumbling or anything), it only interests the script if the clonk is in the air (procedure==FLIGHT) and is in control (ObjectDisabled=0). When there is a call IsJumping() in the clonk and this one is used, the item will only work for clonk types that defined this callback even though the item just meant to check if the clonk was jumping normally. (Which was 100% to read just from the properties of the action)