"I know it when I see it"
Not the easiest definition to enforce, but I think this is the best way to put it.
If we try to nail down this definition of "unfair", we could make ourselves more vulnerable to being rules-lawyered. I don't recall exactly where I saw it, but I do remember that this inspired Stack Exchange's "be nice" policy: there was a forum with just one administrator, whose only rule of conduct was "Be nice." He simply banned everyone who disregarded that rule, and the community was well-off for it. Anyone that knew of that rule and disregarded it via some attempt to exploit a loophole showed that they did understand said rule, and chose not to follow it.
I propose we treat "unfair advantage" similarly. If you believe someone has gained an unfair advantage by updating their language after the challenge was posted or sandboxed, downvote and comment as such. With sustained negative feedback, people will stop being unfair, or stop participating. With regards to the Sandbox especially, very few people see a challenge in the Sandbox (comparatively). If someone's abusing this loophole, that'll be apparent.
I think we should care more about "fun" than "winning". Hence, we should "enforce" fairness when it improves the "fun-ness" of the site, not solely for the sake of fair competition. (Jelly's gonna win everything anyway. :P)
- Bugfixes - Let's say someone fixes a bug in their language after a challenge is posted. (I've done this.) I'd let it slide because I know how frustrating it is to know that your language is supposed to act a certain way, but it doesn't and you get penalized for it. I understand the general "the implementation defines the language" idea, but I think I wasn't around for the discussions. Doesn't the language's creator get a say? In any case, if said person then reverts their change later on, or the "bugfix" doesn't make much sense (or even introduces a bug), that's fishy, and probably would get a downvote from me.
- New features - they do provide an unfair advantage, but only if they're relevant to the challenge. This is already how most people operate anyway, I think.
- When is a (claimed) bugfix really an improvement? Well, how many grains of sand do you have to remove from a heap of sand until it's no longer a heap? There are fuzzy boundaries in every aspect of human life, and we deal with them just fine, considering. I'd likely downvote if a "bugfix" confers a substantial advantage, like more than a handful of bytes or percentage points (about 5, in both cases).
Note: I only suggest downvotes and not deletion because unfair answers are merely bad, not invalid. (In my opinion, that is.)
Fuzzy and murky, yeah, but ultimately, I think this is the best way to go.