I'm not a big fan, as it makes the API even more complex and I don't really see a big requirement of having an arbitrary number of transclusion slots. But let's see what others have to say.

Indeed it makes it a bit more complex.

Yet, in all fairness - multi-slot transclusion itself is still new, makes things more complex but it was really necessary (in my opinion).

Personally I've encountered the requirements for this to be dynamic very soon after migrating to 1.5. One use case is explained in the example I provided.

Currently we duplicate some code because this feature is missing, particualary template code.

We considered various other approaches, particulary using 'require' and extending controllers.

The only feasable and readable approach we found so far is to extract parts of the abstract component into other smaller components (e.g. the header and content cells of a table) and then re-asamble them into the specific needs of each case.

Of course other more unintuitve ways to avoid code duplication are possible (e.g. writing some content manipulation directives), but we prefer a clean, clear and simple direction.

If anyone has other suggestions on how to solve the use case without dynamic slots, let's discuss.

+1

+1. This would reduce a few of my templates by aprox. 80% of it's original length if I were able to use an arbitrary number of transclusion slots w/o being bound by thetransclude: { ... } syntax.

+1