Optional parameters before static text have never been intented to be supported. So this is not a fix but a new feature request. So definitely not for 2.0.

Well, this intention was never specified anywhere in the documentation. The documentation says that route patterns may contain variables and variables may be optional, if a default is specified. So, I would still consider not supporting optional variables before suffix a bug. What is the rationale behind explicit intention of not supporting it?

This sounds great, i had problems regarding this issue also. But i am also not sure if it would be better to only release it for 2.1

as long as there is no regression involved in this, i see no reason wyh symfony should not support this feature. might be something for 2.1 though - hope its not too late there, already in beta too.

It's definitely a BC break.
Path /bar.html will now match Route('/bar-{foo}.html', array('foo' => 'foo'), array('foo' => 'foo|bar'))) (which is the point of this PR).
But previously it probably matched another route that was defined after it.

@Tobion good point, but IMO /bar.html not matching '/bar-{foo}.html' with defaults for 'foo' was a result of a bug. I'm not sure if breaking something which was relying on erroneous behavior is a BC break.

So, how should we proceed with this? If there is no way to merge it into 2.0, I can rework the PR for 2.1, but I really don't see a point in holding it until 2.2. Thoughts?

I suggest to open a PR against master and then we can review it for 2.2.

Btw, I don't understand your use case. You say you want to have a path like
/products-by-{criterion}.html with criterion defaults to popularity. But then your default route would be like /products-by.html which does not make sense. So you cannot achieve that with a single route definition anyway.

In my opinion it is really weird if /bar.html ist matched by /bar-{foo}.html because the dash(-) is not part of the optional {foo} parameter. At best /bar-.html should be matched. Otherwise /ba.html oder /b.html could be matched as well.

I see that the dash(-) can be seen as some kind of separator which can be ignored if the following parameter is optional and missing but from a naiv perspective it would be really confusing.

It would make more sens to mark the optional parts with parentheses like in regular expressions:
/bar(-{foo}).html

Then the idea with /products-by-xxx would even make mor sense:

/products(-by-{criterion}).html

@Tobion I still consider this a bugfix, so IMO it should be included in 2.0, or 2.1 at least. Let's try to gather more opinions on that.

As for my use case:

pattern: /products-{sort}.html
defaults: { _controller: MyBundle:Products:list, sort: 'by-popularity' }
requirements:
    sort: 'by-popularity|by-price|by-name'

works perfectly with my fix.

@laszlokorte With current Router /bar is matched by /bar-{foo} route (if foo has a default), I don't see anything weird in that. The separator preceding an optional variable is included into variable's subpattern.
My fix only allows it work the same way when you add text suffix (i.e. fake extension), making /bar.html matching /bar-{foo}.html route (only when default is set for foo). Additional syntax you are suggesting is not required, because you can just capture the by- inside the variable value (see my example above) and cut it off in your controller if required.

I agree with @laszlokorte that there should be a syntax or an option to specify the delimiting chars for optional parameters.
Because the current implementation assumes the previous character to be the delimiter and as such can result in some weird and unintented behavior:
A route like /prefix{param} with a default for param will also match /prefi which is ridicoulus.

Btw, the implementation is only half-done as far as I see it. You didn't adjust the UrlGenerator, so generating such a URL with an optional parameter with text suffix is not consistent with a URL without text suffix.
Given your example

pattern: /products-{sort}.html
defaults: { _controller: MyBundle:Products:list, sort: 'by-popularity' }

generating this route without any params should result in /products.html but it currently returns /products-by-popularity.html.

Closing this PR as the current behavior is what is expected. The ending .html is a static segment like any other one.