TL;DR
I’ve put together a Google Form, where you can vote on the implementation you prefer and provide an option for the name of the attribute/keyword:
https://goo.gl/forms/Q0nORDF7lbrpeGrF2
Read on for more details…
Both of these just seem to be syntactic sugar that’s equivalent to using ‘block’ yourself and don’t seem to add much of anything. There should probably be a third option on the form for people that don’t think that either implementation is a good idea.
Getting a consistent model so users know where the setting should be is key. I’d argue the block fix seems to be more of a workaround for a regression added in 2.5. A block has no logical connection to the includes it contains, so the workaround is unexpected special case behavior when a include is nested inside a block.
That leaves either the keyword, or argument. Since a apply keyword only makes sense for includes, I’m tending towards a argument. The ongoing changes to include mechanisms indicate they is not the stability to justify locking down a keyword yet.
A block has no logical connection to the includes it contains, so the
workaround is unexpected special case behavior when a include is nested
inside a block.
I agree, and it's a nasty surprise for people who don't happen to know this
special-case.
-- Abhijit
Tasks inside a block already inherit keywords applied to the block,
this is normal, documented and intended block behaviour, having it
cascade on included tasks was always how it was meant to work.
I agree that a new method for include is a syntactic sugar, it would
be the equivalent of making a block just for the include and applying
keywords. That said, i can see why users would want to assign those
via the inlclude itself w/o having to rely on another structure.