There is another alternative that might be worth getting opinions on—Juliusz and I both thought it seemed a bit complicated, but it would have some additional benefits, so here goes.
Firstly, we'd add cucumber tags to indicate the additional role dependencies of a given feature (or individual scenario). For instance, editor_ve.feature would include a `@visualeditor` tag and notification.feature would include an `@echo` tag. Secondly, we'd restrict the default behavior of cucumber (via puppet) to run only those tests that are tagged with any of the currently enabled roles.
The major upside to this approach would be that only those tests suited to the current development environment get run—ostensibly these are the only tests the developer would care to run—translating to far fewer false negatives and more confidence (and utility) in the test suite. With the dual-roles approach, it's highly likely that developers will continue to run into these soft-dependency issues. And, as already stated, a single-role approach is less flexible and will bloat the provision and git-update times.
The biggest downside to this approach is pretty obvious, I think: It would require the author of the test to know and include any role dependencies in the list of tags. Is this a reasonable expectation of developers and/or project managers (who might one day be writing features)? Another possible downside is that altering cucumber's default behavior might confuse people as to why some tests are being skipped.