Null values don't work as expected

Installation & Configuration Bug Reports
1

Here's a Draw widget I'm working on:
OSC Draw

 
The data shape I'm expecting to consume in the target application is:

type DrawEvent = 
  | [x:number, y:number, pressure:number, eventType:EventType]
  | [x:null,   y:null,   pressure:null,   eventType:EventType]

type EventType = 
  | "start"
  | "move"
  | "stop"

 
If I send the null variant with an automatic typeTag, I receive

[x:string]

rather than the expected

[x:null, y:null, pressure:null, eventType:string]

 
I've tried these alternatives:

fffs:  same as auto
,fffs: [x:null]

 
Changing the sent values from null to false works with auto and results in

[x:false, y:false, pressure:false, eventType:string]

but this isn't ideal since it eliminates the potential to use nullish operators.

 
The best solution I've found is to use fffs as a type tag, and send false rather than null. This results in the expected values:

[x:null, y:null, pressure:null, eventType:string]

 
If false on a float type is being interpreted and sent as null, shouldn't null values exhibit the same behavior?

2

null arguments have a particular treatment in open stage control as writing null (in a button's on property) used to be the way to send no argument, that's why null arguments are currently stripped out of osc messages. I don't think this behavior is still relevant today except for backward compatibility and it would make sense to remove it eventually. Meanwhile you could circumvent the issue by sending an empty string instead of null and leave typeTags to auto.