If you want to match ```/users/``` (the list of users, it's a silent fail (the worst kind of error) to also match ```/users/123```, and that's a very typical scenario:

``` gherkin
Given I edit user 123
When I save changes
Then I see the list of users
```
If I match ```/users/123``` as ```/users/``` the site might be at the edit form showing validation errors, and my test (using ```.displayed?```) would just succeed: :fire:.

If I want to prevent this using regexes, the syntax gets uglier, specially if I want to allow query string parameters or a hash.

Having regex to match urls is super flexible, but it's just too generic for the specific problem of matching urls, it's well-known that regex strengths don't include readability, and that's what cucumber and capybara tools are all about.

This problem we're talking was already thought and solved on rails and any other web framework or http routing system out there: they support regexes as fallback, but provide a simpler syntax based on wildcards and tokens.

String matchers are not "woefully insufficient", they are de-facto standard for url matching on every framework I know. Although this naive wildcard implementation is, I agree.

The same issues you'd have with a regex like ```/\/accounts/i```, so a bigger and more complicated regex would be needed, making it harder to write and read.

But fortunately great url matching gems are available and Addressable is already used to build urls by SitePrism, sounds like a perfect fit to use it for matching them too (using the same string matchers). 

So yes, I closed this one, and proposed using Addressable instead.