Thank you @aitboudad.

@fabpot there is actually a BC break in this change: parent::parse() returns a TemplateReference from the component, not from the bundle, and calling $ref->get('bundle') on it throws an exception, because the component does not know about the bundle parameter (see the code of the TemplateReference for the exception being thrown).
I see 2 ways to fix this:

• return null for other parameters rather than throwing an exception in TemplateReference (especially given that the outer code has no way to know which parameters are known other than catching this exception)
• change the template name parser to replace the TemplateReference by a FrameworkBundle one

what would be your preferred way to fix this ?
the second option would be the closest to BC, while the first option would be the one making the API more dev-friendly

Note that AsseticBundle is affected by this break for instance (this is how I found it)

I think option 2 would be better.

Actually, the option 2 is not good, because some of the parent references cannot be represented with a FrameworkBundle reference (it forces the logical name to have template.format.engine while the component reference does not have any restriction).
So here are the 2 solutions I see:

• the option 1 above: return null for unknown parameters
• restrict the FrameworkBundle parser to parsing template.format.engine when it cannot parse it as the bundle:folder:template.format.engine notation instead of using the component implementation

Btw, the name parameter has a different meaning in the bundle and the component, which means that passing a bundle TemplateReference to the component PHP FilesystemLoader will break