I discovered this bug when cleaning up a test business after illustrating a point in response to a forum question.
When trying to delete a number-type custom field:
the program correctly raises a warning:
But, when editing one of the objects (Sales Invoice 7 in this example):
and deleting the field content:
then updating the object, the object remains on the list. When returning to edit the object again, the original number is gone, but it is replaced with text of unknown origin:
The same thing happens when trying to delete content in the custom field for all other objects. The same “NaN” text appears and cannot be deleted. That spurious text content also cannot be deleted by editing the sales invoice directly in the Sales Invoices tab.
The problem does not, in my testing, occur when the custom field is any another type.
In fact, if the number field is edited by converting it into another type, its content can (in some cases) be successfully deleted and the object can be cleared. After clearing all objects, the field can be deleted.
However, if the only content in a field was the spurious “NaN” text, that text sometimes disappears when the field type is converted to something besides a number. (This happens when converting to dates.) Yet the object still cannot be cleared from the list of referenced records. In such cases, only if content matching the new field type (a date) is entered, then deleted, and updated does the object disappear from the list.
In summary, number-type custom fields seem to have a second layer of content comprising the text “NaN” that cannot be deleted, yet may appear only when the field type is Number. This second layer prevents deletion of a custom field.