I tend to make Composition Components as Element Types. Any reason in V15 not to do so? Any plans for the new back office means I should make compositions in a new way?

Don't think there is. There is an added benefit of doing them as elements, as they can then compose other element types too 🙂

> they can then compose other element types too I did not know that! So only doctypes cannot be nested more than 1 deep? I will try that today - thank you @skttl

Oh sorry, forgot to mention. The UI wont let you compose more than 1 level deep, but the API has no problems with it (as long as you don't create circular dependencies etc.). If you use uSync or Deploy you can add compositions through usync/uda files, and import 🙂

As soon as I replied I was thinking, since Block Grid and Block List I haven't really needed to nest any deeper than one level in compositions. Also I am not sure it would be great for maintenance by a team. What I was also wondering is if there were plans to merge the Block List and Grid Component directories so a single element type can work in both off the shelf. I know it can be done with rerouting etc… Also what will 'variants' change? Apart from that I am enjoying messing around in V15.

I've used multicomposing in the past, to have eg. a general Settings composition, that is then composed by single content types for eg. Meta, URL settings etc.

Something to be aware of, IPublishedElement's (i.e. the composite interfaces) don't have the same properties as IPublishedContent - so if you had an SEO one but needed to access the URL/Name you'd need to re-cast it back to IPublishedContent with some type matching. It does depend on how you are using your compositions. Just throught I'd mention it