We can't find any flaw in the spec. Please propose requested changes or join the UA call to discuss.

Here are the proposed changes:

Delete the following sentence since the DataValue definition (7.7) describes no way to not indicate the UtcTime fields shall be considered Null. Since UtcTime are DateTime they only have earliest/latest date/time values which is not specified to mean "null" or "unspecified" value.
In part 4:
Table 59:
If the SourceTimestamp or the ServerTimestamp is specified, the Server shall
use these values. The Server returns a Bad_WriteNotSupported error if it does
not support writing of timestamps.

Fix the following sentence for the same reason, there is no specified way to indicate Utc timestamps as "null" value, nor to indicate status code as "null" in the DataValue. Therefore those values are always specified at least with default values (earliest timestamps for timestamps, "Good" status code for status) and there is no way to know if the client "attempted" to write those metadata or not. Except for the Variant which can be Null there is no real "combination" possible due to absence of Null values defined for metadata fields, as a consequence it seems to me only the IndexRange case should be kept (last sentence).
Table 61:
Bad_WriteNotSupported: The requested write operation is not supported.
If a Client attempts to write any value, status code, timestamp combination and the Server
does not support the requested combination (which could be a single quantity such as just
timestamp); than the Server shall not perform any write on this Node and shall return this
StatusCode for this Node. It is also used if writing an IndexRange is not supported for a
Node.

A server should always be able to detect a null DateTime value since there is not timestamp transported in the DataValue if the client does not write a timestamp and the null DateTime is created by the local stack.

If the DateTime value for the timestamp is not null and the server does not support writing the timestamp, the server must return the status BadWriteNotSupported.

This is a necessary feature and it makes no sense to change this..

As stated in my previous comments, there is no such way to have null DateTime in the encoding of DateValue, only minimum values are set and not null values.

It might be solved if the fix for the following issue is to change the meaning of the encoding in specification part 6:
https://opcfoundation-onlineapplications.org/mantis/view.php?id=4651

Best regards

An OPC UA application must be able to identify a null DateTime that was created by itself.

See the following detailed definition on how to handle this in OPC UA Part 6
https://reference.opcfoundation.org/v104/Core/docs/Part6/5.2.2/#5.2.2.5

Agreed to no change required.