This isn't so much a bug-report, as it does not really "break" the router.
More of a change to validation on the router.

When creating DNAT rules you have the ability to set the address to translate to.

dickins@gateway# show nat destination
 rule 5 {
     destination {
         address 1.2.3.4
         port 24800
     }
     inbound-interface eth1
     protocol tcp
     translation {
         address 10.242.0.33
     }
 }
[edit]

In the above example, inbound packets to TCP/24800 going to 1.2.3.4 on Interface eth1 are re-written to a destination of 10.242.0.33.
However, the validation of creating a DNAT rule gives you the following options;

dickins@gateway# set nat destination rule 5 translation address
Possible completions:
   <x.x.x.x>    IPv4 address to match
   <x.x.x.x/x>  IPv4 prefix to match
   <x.x.x.x>-<x.x.x.x>
                IPv4 address range to match
   10.242.0.33


[edit]

The above examples, when configuring - implies that you may use a subnet prefix or IP range when creating a NAT rule.
When in reality - you're only able to set a single IP Address.
Setting a range does not forward any packets and the router does allow you to set a range.

How I came across this issue?
I wanted to create some kind of load balancing.
Basically I've got three computers which all accept this connection of TCP/24800.
I thought it would be a good config to set a range of IP's of which the PC's are on and perhaps NAT would "round-robin" connections until one connects.
That was not the case 😆