TL, DR: From what has publicly disclosed, you have no influence on Z-Wave routing.
Unlike the Z-Wave application layer, PHY and MAC layer specifications, Z-Wave's networking layer spec hasn't been publicly released-- per the Z-Wave Alliance this was expected to happen 2H 2020 (see Silicon Labs and Z-Wave Alliance Expand Smart Home Ecosystem by Opening Z-Wave to Silicon and Stack Suppliers - Z-Wave Alliance ); AFAIK that hasn't happened yet. So the reason why nobody seems to know exactly how Z-Wave routing works is because thus far the details are proprietary. That hasn't stopped people from reverse-engineering it, especially those in the network security business.
The best description I have seen of how classic Z-Wave routing works can be found here (skip to section 4): The Z-Wave routing protocol and its security implications - ScienceDirect. Unfortunately it omits any discussion of explorer frames which were added in later Z-Wave versions; these allow devices whose tables contain no working primary or alternate route to obtain one-- but it is bandwidth intensive, essentially flooding the network for a period of time and not intended as the 'front up' mechanisim for route discovery/maintenance. That is the job of the Z-Wave controller, since it (and not the peripheral Z-Wave device) maintains the list of all adjacent nodes.
A few points stand out: Routes are computed by the Z-Wave controller (not the device), distributed to each node, and maintained in a 'source route' cache of target nodes on each device. More than one viable route is computed to allow tracking the last working route as well as an alternate path in the case of failure of an intermediate node; if the path through a given route is not acknowledged, after three attempts an alternate is tried before giving up. For routing-capable devices, an additional cache of 'backbone routes' (paths from the device back to the central controller) is maintained. If a routing node hears a route request from another node, it can transmit the backbone routes to a potentially stranded node with a stale or corrupted cache as a recovery mechanism.
Aside from the case of failed route recovery using bandwidth hogging explorer frames, the only routing function performed by a non-controller Z-Wave device is to report a list of its adjacent neighbors to the controller on request. This is the mechanism of Z-Wave repair, implemented with the NL commands described in the article in sec. 4.2.3 in the article. From the neighbor list reports, the controller maintains the only complete node adjacency table, then computes and distributes lists of routes to each node.
Regarding route prioritization, not much seems to be known. Section 4.2.1 in the article indicates that there is a byte field in the source route data structure that sometimes prevents a distributed route from being used by a recipient node; in other cases the route is given a lower priority and only used when other routes have failed. In any case it is the controller that determines route priority, not the device.
Unfortunately with the unknowns regarding the networking layer, combined with teething issues of the 700 series (RSSI reporting and 'sticky' Last Working Route issues -- see How to Upgrade Your 700 Series Project from SDK 7.12 to 7.13 – DrZWave ) the odd routing observed probably shouldn't come as a surprise. Whether it is working as intended or not seems to be unknown, as well.
