In my opinion, there are two distinct issues at hand when dealing with NULL values,

1. Display of nullable fields that carry a NULL value

2. Post null values from the UI to the backend

But before we stride any further, let us look at a few considerations,

a. Value space - Each data type typically has a value space. A value beyond the value space either requires us to either redefine the value space (for inclusion) or ignore the value (exclusion scenario)

b. Posting of NULL values - The choice of whether to OR not to emit the default value of an attribute depends on whether you control the other end of the wire (i.e. the processing of Null values)

Now heading over to the solution approach, 

1. Display can be handled by creating a web block for every control that we need to account for as nullable, from a display perspective. e.g. a web block for displaying nullable number or date attribute.

The web block is responsible for intercepting the NULL/ Defaults and replacing it with "" i.e. empty string or a recognized substitute that conveys the meaning of NULL on the UI

2. Now, as far as posting NULL values to the backend is concerned, there are two primary scenarios i.e. posting to APIs and posting to Database

While posting to APIs (which serialize entities and structures to JSON) all that is required is to have the underlying entity/ structure bear the default value while you set the property Send Default Value = No

On the other hand, if you are posting the NULL value to the database, from the SQL widget, use the Expand Inline property of the input parameter to form a legitimate SQL command that leverages the SQL NULL

So, until we have some cool feature released by Outsystems, yes, there is a bit of effort involved in setting the above, but if NULL handling is inevitable in your use case, you may commit the additional efforts as they are one time (considering that you develop the above solution as a part of foundation layer)