I've been trying to properly define my tool frame in ROS so that it matches the tool frame of the physical robot. Doing this requires changing the following lines of code in the URDF:
You're not actually supposed to change tool0 in any way, one of the reasons being exactly that this doesn't work with the IK plugins we provide. The IK plugin works with the base_link->tool0 chain and is generated code, changing tool0 will result in mismatches between what the plugin expects and what your actual model provides.
The tool0 frame is described both in the Create a URDF for an Industrial Robot tutorial, section Additional/Standard Frames, as well as in Working with ROS-Industrial Robot Support Packages, section Standardised links / frames. The former has this to say about tool0:
tool0 The tool0 frame (pronounced: 'tool-zero') shall match exactly an all-zeros TCP configuration as defined on the robot controller. For most controllers, this is equal to an unconfigured TCP, which lies on the physical robot's mounting flange.
This transform (between the last robot link and tool0) may be defined in any way (so may consist of all combinations of translations and rotations), as long as it is a fixed joint type in the URDF. Users are advised to never change tool0, but instead add additional frame(s) as (a) child(ren) of tool0.
The recommendation is thus to add child links to your composite / top-level xacro that add your toolframe as a child of flange (for robots which have that frame), but in any case as siblings of tool0. This will keep the chain consistent with the IK solver and should allow things to keep working.
One difficulty with this is that in some cases, (goal) poses defined for your new toolframe will have to be transformed back to tool0 before you pass them to a motion planner (MoveIt used to require this, I can't say for sure now whether that is still the case, or whether you can tell it to do this for you).
If you really do want to change tool0, then you could switch to KDL or Trac IK as your IK solver. Both of these can work with runtime defined kinematic chains, so they don't have the problem of requiring the chain to match whatever it was when the code was generated (we use IKFast as it solves in microseconds, as opposed to milliseconds for KDL/Trac IK).
PS: the current definition (and use) of tool0 mixes the concepts of 'flange' and 'unconfigured toolframe', which leads to confusion such as yours. We're working on a revision of our modelling standards that will rectify this, most likely by introducing a separate flange frame / extension point (edit: this flange frame was indeed introduced, and decouples the orientation constraints of tool0 from the eef-attachment-point semantics of flange).
