Roland XV-5080 definition file

By definition any MIDI data byte must be in the 00 - 7F (hex) range: the most significant bit ("bit 7") cannot be used because it must be 0. (MIDI status bytes have "1" in "bit 7".)
This means that any value larger than 7F hex must be sent as a sequence of two (or more) MIDI data bytes.
How this is exactly done, depends on the MIDI device.

The XV-5080 manual on p. 290 explains how this must be done for the XV-5080:

Transmission of "#" marked address is devided [sic] to some packets. For example, ABH in hexadecimal notation will be devided [sic] to 0AH and 0BH, and is sent/recieved [sic] in this order.

So Tone Delay Time's actual value (in the range 0-149) must be sent to an XV-5080 as two MIDI data bytes, each containing four bits of the actual eight-bit value.
The first MIDI data byte must contain the four most-significant bits (bits 4-7) of the actual value. (Note that these bits 4-7 must get "shifted": in the MIDI data byte they must have moved to bits 0-3.)
The second MIDI data byte must contain the four least-significant bits (bits 0-3) of the actual value.

So to make the BCR output the actual value of an encoder in Tone Delay Time's format, you can't use "val" or the equivalent "val0.6": either would make the BCR output bits 0-6 of the actual encoder value as a single byte, which is wrong in this case.
Instead, you must use "val4.7 val0.3": this makes the BCR first output a byte containing bits 4-7 of the actual value of the encoder, then a byte containing bits 0-3 of the actual value of the encoder. This is exactly what the XV-5080 requires.
(For further explanation of the BCR's data specifiers, see BC MIDI Implementation.pdf, section 14.6.1.)

Furthermore, you should realize that BC Manager's parameter range definitions also expect sequences of MIDI data bytes (in hex format).
So that's why BC Manager rejects 95 (hex) as being out of range here.
To determine the MIDI data byte sequence describing a parameter boundary, you can use the "MIDI data calculator" in BC Manager or MIDI Tools:
Enter the decimal value (in this case "149") in the "Decimal"/"Total" field in the "Normal bytes" group, then look at the last two "Hexadecimal" fields in the "MIDI data bytes" group; in this case these will be "01" and "15".
So this is what you must use as the upper bound of the parameter range: "01 15".

So taking all this into account I think the parameter definition should be:
1F 00 20 0A | 00 00 - 01 15 | val4.7 val0.3 ;Tone Delay Time

If the max value the BCR2000 can send is 16383,

Let's be precise here:
In my previous post I wrote

The minimum value of a BCR2000 encoder is 0, the maximum 16383.

But this merely states the range of the internal value of a BCR2000 encoder.
It doesn't say anything (or at least not everything) about what the BCR can send.
That's because what a BCR sends must comply with the format expected by the receiving device; so in this sense "the max value the BCR2000 can send" is undefined: we must always take the demands of the receiving device into account.
Yes, the BCR can only send a value based on the internal encoder value, which lies in the 0-16383 range.
However, a custom output (".tx") definition can include various portions of an encoder value ("val...") and also hard-coded MIDI data bytes, so a receiving device can be "fooled": the MIDI data bytes being sent can be in a format that the receiving device interprets as something else than the internal encoder value. All we have to do is make sure the device receives a sequence of MIDI data bytes that it interprets in the desired way.

The XV-5080 expects to receive an MFX parameter as a sequence of four bytes, each containing four bits:
0000 aaaa
0000 bbbb
0000 cccc
0000 dddd
The XV then converts this to a 16-bit value: aaaabbbbccccdddd. So aaaa are the most significant bits (12-15) of the 16-bit value, dddd the least significant (0-3).
This 16-bit value must be in the decimal range of 12768-52768, with 12768 corresponding with the conceptual (and displayed?) value of -20000, and 52768 with +20000.
Note that this means that you can never have a BCR encoder produce all the values of an MFX parameter: an MFX parameter's full range includes 40001 values, which is more than the 16384 values a BCR encoder is capable of.
There are various ways of working around this. Which method is best, depends on what a specific MFX parameter represents and therefore which values you want to be able to send to the XV.

If you want an encoder to span an MFX parameter's full range but don't need its full resolution, you can make the encoder represent 16 times the MFX parameter's value, as follows:

12768/16 =  798
52768/16 = 3298
So the internal range of the encoder should be 798 - 3298.
This means that the BC Manager parameter definition line should specify a range of 06 1E - 19 62.

Since the XV expects to be sent an MFX parameter as a sequence of four bytes containing four bits each, you can send three bytes containing bits 8-11, 4-7 and 0-3 of the encoder value followed by a byte that is always zero:
val8.11 val4.7 val0.3 00
So basically you "cheat" the XV-5080 by multiplying the encoder value by 16:
Bits 8-11 of the encoder value end up in the SysEx message as bits 12-15 ("aaaa"), bits 4-7 as bits 8-11 ("bbbb"), bits 0-3 as bits 4-7 ("cccc") and 0000 as bits 0-3 ("dddd").
(Side-note: bits 12 and 13 of the encoder value cannot be sent in this situation. But since 3298 (decimal) is the encoder's maximum, bits 12 and 13 are always 0, so don't need to be sent.)

So for instance the definition for MFX Parameter 1 would look something like this:
?? ?? ?? 11 | 06 1E - 19 62 | val8.11 val4.7 val0.3 00 ;??? MFX Parameter 1
Of course you'll have to replace the question marks with the appropropriate area bytes and specification.

Hope this helps,
   Mark.