I think you are right that this is unlikely to be a problem.  However I think it makes sense to leave this as is.  This function will really only be used when the options are being modified.  This typically happens from the UI and is not performance critical.  Also all accesses to KinematicOptionsMap require an internal mutex lock and typically an access to a map which mean that the reference inc/dec will not significantly slow things down.

On the other hand if this fails (RobotInteraction is deleted while UI is modifying the value from a different thread)  it will result in a rare race-condition based memory corruption which will be almost impossible to find.

Note: This function is likely to change in my next batch of fixes where I address thread safety in the RobotInteraction class.  We can revisit then, but to be thread safe I think this function will need to return the pointer and not a reference to the pointer.