issue with creating user annotation values named nan

[seve]

The following behavior is seen on user-created annotation values named nan both manually created and copied from read-only categories:

1. nan -> null upon refresh
2. Manually naming a label nan and then refreshing also changes it to null
3. nan works like a normal label, but null has several bugs, a couple listed below:
4. Hovering on null enlarges dots as expected, but turning those cells on with the checkbox interaction does not enlarge dots (but it should)
5. Selecting just a null label for diff exp, nothing happens when click to make it the first diff exp group, but other labels try to pull in the cells that are in null when I try to add them to diff exp selection

---

HT: @liaprins-czi for the list of behaviors

[liaprins-czi]

On refresh, nan changes to null, within manually created category (also this happens if I just manually name a label the word "nan"!):

(Okay so this GIF ^^^ is too tiny to see the names of the label changing (had to make it this small or the filesize wouldn't fit in this GH issue) but you can take my word for it that this happens on refresh!)

When try to add a label called null to diff exp, nothing happens:

[bkmartinjr]

To clarify what I believe our UI intent is:

• 'nan' is a legal label name, and should be treated as any other label. (side note: it has a slightly magical meaning in Pandas categorical dataframe series, but that is not something which we should special case)
• null should never be a legal label - that is straight up a bug
  Will investigate for 0.14

[liaprins-czi]

@bkmartinjr So do you mean null should not be allowed to be typed by the user as a name for their category? And if we get an incoming .h5ad with a label called null we should somehow transform it or not accept it because as you say "null should never be a legal label"?

I don't know about that ... what I would expect as a user is:

• that nan simply stays being called nan (doesn't automatically change into null)
• if there ever is a label called null (e.g. manually named that or comes in with an .h5ad, etc), it functions just like any other label: is selectable, I can run diff exp on it, etc etc

However you or others may know things about nan or null that I don't know, so let me know if these ^^^ don't match up with what you think the user would expect, or if they are not easily possible from an implementation standpoint.

[bkmartinjr]

the string "null" should be allowed, as it is a perfectly legal (if weird) tag name.

I was referring to the JS null type, which was a side effect of the underlying bug.

This is all confusing because "null" is a string, whereas (in Javascript) null is a type/value. Same confusion/distinction between "NaN" and the floating point value NaN