> However, stepdefs are the domain of the testers so it should be readable for them.

I think the traditional automated tester (post-implementation tests)
is more or less dead. I understand that I created the
Developer-in-Test role, but it was because under the cloak of "QA" we
could hire second generation Xp programmers (in fact, Andrew Premdas
wrote the original job description and "competencies" and the role is
now surprisingly becoming an industry standard). The step_defs are the
domain of the developers - however high the DSL - it is code.

If a tester wants to code then he becomes a developer and he also writes
production code in a test first manner. Developers write automated
tests, not testers.

All code should be readable to those who read and write code, but the
idea of pushing automated tests so high that a tester or BA could
write automatic tests is in fact an old one. This was the promise of
the last decade in keyword or "data-driven" automated test
architecture, where testers could just enter keywords and the code
beneath would run the tests. However, the code beneath broke and a
developer had to fix it. It was wasted effort, that I feel you may be
attempting to reproduce.

The weakest area of BDD is the collaborative writing or actual writing
of features - and any improvement in that is obviously commendable.