Yes, I think this is exactly right (not just in what Scrum/XP says, but also in how it has to be). Separating that role is super important and is potentially one of the friction points in transitioning from a more traditional setup (as evidenced by TFA). In my experience, it is also very, very important that the Scrum Master is
not the manager of the team. It has to be someone whose accountability is to the technical success of the team as distinct from the delivery of high level objectives for the team. In a more traditional setup that would be someone like a team lead, senior dev or even a system analyst. XP doesn't define this role specifically and it is probably a weakness -- I've done it as a coach, but usually I appoint someone on the team to do it.
Also, interestingly, I've often had project managers who refuse to do the PO role (I usually call it the "Customer Proxy", but it's the same role). In those cases I try to appoint someone who is accountable for writing stories. They consult with the project manager for the higher level "vision" (but in practice the project manager does virtually nothing -- a state of affairs which they are usually quite familiar and comfortable with, unfortunately). Prioritisation of stories is done by the development manager, PO and project manager (if they are different from the PO). In this case, the Scrum Master/Coach is not invited to that meeting.
To answer the original question: How do you represent the acceptance criteria? Personally, I do not like code based representations of acceptance criteria. Having said that, my entire exposure to them is working on legacy projects where they have gone badly wrong.
The main problem is the same problem with trying to maintain prose documentation of the requirements of a large system -- those requirements are at least as long as the implementation of the system. They are also at least as complicated. We've slowly created ways of organising production code to make it easier to manage. The same is not true for BDD style acceptance criteria, or even prose requirements documents.
At the beginning of my career I spent a lot of my time writing requirements documents in prose. Every 6 month release would include something like 1300 pages of requirement documents. Maintaining these requirement documents was impossible. Very quickly they get out of date and so you no longer have any description of the working code other that the implementation itself.
Based on these experiences, my attitude is that requirements (including acceptance criteria) are ephemeral. They exist for the life of the story and then you abandon them (note: I'm still massively in favour of acceptance tests and unit tests, but implemented as code that is written in a similar way to the production code -- because we have techniques for managing that complexity).
Long story short: I write them in prose on the story and appoint someone to making the determination whether or not the acceptance criteria is sufficient to add the story to the sprint commitment (as nradov explained in much fewer words than I did :-) ).