Sure that makes sense given the "go further" piece -- so I could understand removing the test in that case (from 2019-09 only would be my preference -- where I think that language was added explicitly because some implementations e.g. mine implemented it because the spec didn't say not to) if the point is "the spec explicitly calls this undefined behavior".
Having some tests that test beyond just valid/invalid is so far out-of-scope for what we had but I agree it'd be nice to have. I've never seen that as belonging in this suite specifically, more in some pathological suite with things like circular references (which are to me the canonical example), but where exactly that lives I guess isn't a big deal, maybe here.
My point though is I don't really like the specific move from this PR -- to me, either they should be moved to a pathological place that doesn't deal with valid/invalid (if the goal is to use them to test edge cases beyond validation), or if there is some intention that an implementation may want to implement that behavior (as, again, to me, was the case pre-2019-09), that was what I was responding to (that there's not much of a difference there between "optional and defined" and "optional and undefined", at the end of the day the difference is just "you may or may not want to include this file in your implementation's runner")