If you set up a widget buffer, the field will appear as expected with a 0 as initial value.  The problem starts if you try to clear the field and then enter a new value, say by hitting C-k, and the problem is in the :value-to-external functions in the in sexp and restricted-sexp widgets (the number, float and natnum widgets must also be fixed).

The library :value-to-external functions eventually do a (read value) where value is the widget value; alas, value can be "" if you edit the field in a pretty standard way, as, as I said above, if you had tried to kill the field line (C-k); this causes the traditional minor demons to fly out of the nose, as a 'End of file during parsing' error gets signaled.  After that, the buffer with the widgets is pretty much in a random state.

Specializing the widget with a hack like the function below fixes the problem, but a

good solution may need some more work to get all the corner cases.  Note that setting a "widget buffer" in overwrite mode goes a long way to mitigate these problems: maybe having widget-setup switch to it would be another good thing to do.

  :value-to-external
  (lambda (widget value)
    ;; Lifted, and fixed, from `:value-to-external' in
    ;; `restricted-sexp'.

    (unless (stringp value)
      (display-warning
       'widget-bad-default-value
       (format-message
        "\nA widget of type %S has a bad default value.
value: %S
match function: %S
match-alternatives: %S"
        (widget-type widget)
        value
        (widget-get widget :match)
        (widget-get widget :match-alternatives))
       :warning))
    (if (and (stringp value) (string-equal "" value))
        ;; Oooops, we cannot just `read'.
        (widget-get widget :default-value)
      (read value))
    )

Note: this goes back, at least, to 25.x.

Thanks for the attention

Marco Antoniotti