So I agree that this is a real point of contention (and said as much in the Kingmaker post).

If the problem were merely just the distinction between “a winning team” and “the winning team”, then that would argue in favour of FOR – there clearly isn’t more than one winning team at the moment, so the distinction shouldn’t matter in that sense.

The question boils down to whether the word in the rule refers to the word in the team name or not. I strongly feel that if it does, this is a bug in the core rules, that should be fixed with an appendix change (although I’m not sure how it would be worded) – we already have a rule like that for Meeple names. That said, I am not confident that the bug isn’t there presently.

(It’s also worth noting that the name is defined as not being flavour text – that in turn implies that it should potentially have some impact on the rules, because that’s what not being flavour text means.)

This wouldn’t be the first time that someone used a free-form variable to match a rule term. If that’s a bug, then it’s been a long-standing one. I agree that wording a fix would be tricky.

On an unrelated note, I will vote against an appendix fix for this class of scam. The fix is already there, and it’s making the variables in question flavour text. I don’t think we need to go to such lengths to protect ourselves from ourselves. Doing so dilutes the game IMO, it’s nice to have things like this happen once in a while when the flavour text protection fails (as it may have in this case)

@Habanero: I was posting an Appendix fix while you were writing that, because I came up with a wording that I think works. You have made a good argument to not enact it, though!

I guess the tradeoff here is “occasionally we mess up a dynastic rule and someone scams it in an interesting way” being a good thing, versus “we have to explicitly make freely choosable names flavour text every time, making the dynastic ruleset longer and harder to read” being a bad thing.

based on this sort of thing having worked in previous dynasties.

Habanero alerted me to the initial mistake, which is when I added the “where this string is considered flavor text”, which as we see only confounded the problem. It’s a lesson in clear rule text writing, which I agree is worth learning each time rather than “protecting” ourselves from it.

I think the trick to get clear wording is to always separate the definition of how a variable works from the rules for changing it. When I’m adding a new variable, I start off by saying what it’s called, who or what has instances of that variable, and what values it can have – I also think about how to fairly initialise it for new and unidling players. Then the rules for changing it are separate, usually in a different paragraph.