This should remain as string? Text initialised to null

(Sorry, my original comment wasn't very clear: with it nullable we need to add checks when calling into MathRenderingExtensions)

This will entail a whole series of checks during the rendering stage.

I think that might be inevitable. I'll take a closer look now, but I don't think we can change the default to non-null in a hurry.

I only see problems with this if users with Nullable disable can sometimes have null instead of this value. But this will result in an NRE for them anyway.
While exceptions will let the user know that they forgot to set the Text property, the very use of TextualAnnotation implies this.

It's the same problem as ImageAnnotation.ImageSource etc.: it has to be set, but there's almost 10 years of code that might not be initialising the object all at once, and may even be using null to signal to different parts of code that it needs to be changed: changing the default at this point will cover-over failing to assign the value, and be a silent code-breaking change for some users. Perhaps we can try to gauge how big a deal this will be?

Regarding the last point, PointAnnotation and friends don't actually require the text property to be set; however, the behaviour won't change for PointAnnotation with your proposal, but it may change the behaviour of consuming code. It may just be the old versions of everything we're using, but I'm surprised by the error in that case, as the usage is within an if (!String.IsNullOrEmpty) check.

Looking back at old posts, I think my previous remarks express my current feelings rather well:

I think the main benefit we might see from this will just be in informing us where we should be throwing more helpful errors. Short of breaking every plot element in two, I don't think there is too much we can achieve to tighten the API, so it will mostly be limited to expressing which things may be null, which dilutes the meaning for those which are expected to be null.

The problem is that OxyPlot is basically a bundle of mutable objects without defaults (which means that null signals something to the consumer). This (TextualAnnotation.Text) is obviously a case where I'm advocating for making something nullable because it might happen to be null, rather than because it is intended to be null.

@Jonarw has previously described the possibility of just leaving nullable off for certain types; I'm going to do some reading/experimentation to see if this might be a possibility in these cases. I've previously been opposed to this, but I could certainly buy the benefit of having nullable annotations on all methods but omitting it on a class of properties if it's not too misleading for the consumer. In particular, we could leave these unannotated now, and then annotate them e.g. when we have required: benefit of required is that it expresses the intention well, means simple and correct code will continue to work fine, and will noisily break old code, so is OK for a major release.

I'm torn between respecting the type system - which tells me to keep these nullable and use documentation to talk to the user instead - and trying to express the intention that these should be initialised to a non-null value by the user - which tells me to make these non-null and just initialise them to null anyway (is there any precedent for this in other libs?). I'm definitely opposed to adding non-null defaults for everything at the moment, though in this specific case, perhaps string.Empty would be OK..

Sorry, no decisions in there... I'd like to take a bit more time to think about this. My instinct still is to keep them nullable, and add more useful exceptions and inline documentation. Feel free to dump any vaguely relevant thoughts you might have here.

Pinging @Jonarw again should be want to jump in on this