So apparently I can fix this myself by adding a dummy ROAD definition. Sorry to bother you all with this!

Version of OpenTTD

20200713-master-g706c47265e

Expected result

This is a tricky one to explain. The expected result, according to the NML specs, is that NRT roadtypes have "outbound compatibility". This is the result I get, and the result that every NRT GRF is programmed to use. However...

Actual result

Railtypes, which have "inbound compatibility", are made compatible in NML as follows...

My TST2 NewGRF
compatible_railtype_list: (insert TST1 railtype made by someone else)

...and in this example, result in trains meant to run on TST1 will also run on TST2.

But roadtypes are compatible in NML as follows...

Other Person's NRT2 NewGRF
powered_roadtype_list: (insert my NRT1 roadtype)

...and road vehicles meant to drive on NRT2 will also drive on NRT1.

Technically, the actual result is EXACTLY what it's said to be, but in practice this means that whichever roadset replaces the ROAD roadtype is the one which defines whether ROAD vehicles can run on roadtypes provided by other GRFs.

I have already tested adding ROAD to "alternative_roadtype_list". All control over whether a ROAD vehicle can travel on any other GRF's roadtypes is in the hands of the NewGRF creator who created the replacement for ROAD.

I would like to propose minimal code changes, that NRT would use "compatible_roadtype_list" to provide inbound compatibility, or that "alternative_roadtype_list" will act as a fallback for other roadtypes even when the roadtypes listed are available.

Steps to reproduce

The simplest way is to use URaTT 0.2 or RaTT 1.0.2 with eGRVTS NRT r204 and WaterWayRoad 0.3.1, then try to get a road vehicle to cross the River Ford roadtype (FORD).