Most problems had, in my opinion, pretty short (and uncomplicated) implementations.

• GPL: couple of if conditions, which imo are fairly natural once you solve the problem.
• XRSM: probably the worst of the bunch since you can get stuck in if-statement hell, agreed (as was mentioned in another comment, alternate solutions exist, but I'd still judge it by the one most people coded in-contest)
• CKCUT: one loop to populate updates, a single prefix sum, then another loop to compute the answer; no real casework needed
• SMXOR: once you have the solution, again very simple implementation, no casework
• TRCLR: there exist $$$\mathcal{O}(N\log N)$$$ solutions that are perhaps slightly long, but there are also $$$\mathcal{O}(N)$$$ solutions that need only one or two DFS-es. The linear solutions require minimal casework (or even none).
• TIKI: also quite short if you treat NTT as library code

The non-div $$$1$$$ problems are trivial to implement.

CKCUT is perhaps the biggest loser here: I think it'd have been much better if we'd included an image or two to explain things.
I'm curious though: if you (or anyone else) misunderstood the statement entirely to be something else, can you share your interpretation? The only one I've heard so far is one person assuming that when a flavor is applied, it overwrites any existing ones (though that interpretation immediately fails if you look at the second sample).

In my opinion (and I hope you agree with me here), the other statements are fairly alright: GPL, XRSM, TRCLR are just formal statements, and SMXOR is mostly formal (except for the one line about Leo forgetting the array).
TIKI has a pretty long statement, but that's partially because there are several definitions to be made and a few examples within the statement itself. Imo every part of it is relevant to ensure there's no ambiguity in the passing process and what sort of sequence defines the score. I also chose to explicitly mention certain situations in the statement (such as what happens when the ball passes through the center).

I probably could've made it a bit shorter as-is, but likely the only way to make it much shorter would be to write a formal statement about a circle and simple polygons in it, which loses the flavor of the problem entirely.

As a final note to anyone still reading this, if you're ever confused about a statement, you can ask for a clarification using the "Comments" tab, and if it's a reasonable question someone from the problemsetting team will respond soon enough.

Probably wasn't the greatest, true.

I personally found SMXOR and TRCLR to be of similar difficulty, so I didn't have a particular opinion about their ordering.
SMXOR is definitely more standard of the two, and I'm not too surprised that Div1 found it the easier problem (as a side note, I expected a lot more ACs on both these problems in Div1).

CKCUT also I found simpler than XRSM, I think prefix sums are easier than doing casework. If I had to hazard a guess, the difference in solve counts comes from the fact that XRSM was solved first, so for most people it became the second problem they tried rather than the third; and then they got stuck in casework.
I observed a similar scoreboard effect in Starters 127, when the hardest problem of the contest got solved pretty early which made a lot of people try it (and it was easy to come up with wrong guesses to it, which exacerbated the issue) instead of the easier problems.

I assume you're talking about CKCUT and SMXOR, where the arrays were given in two lines rather than $$$N$$$ lines of two integers each.

I did notice this, but decided it wasn't worth changing — for languages that read input line-by-line (hi Python), this input format is vastly superior since you read way fewer lines. If the input is large enough, it can drastically bring execution time down.
CKCUT probably would've been fine with the traditional style, SMXOR might actually have had issues with the time limit (my PyPy code already runs not-too-fast with the current format).