And what makes you feel 'editprotected' would be inappropriate for this purpose? Cascading protections are still protections, not something different level of protection.

Because 'editcascadeprotected' can be temporary.
For example now (August 16) you can not edit "Wikipedia:Selected anniversaries/August 16" on en.wikipedia, but you can edit it on other days.
So 'editprotected' is not like 'editcascadeprotected'; a user with 'editcascadeprotected' right should not be able to edit all protected pages like 'editprotected' right.

If you can edit cascading-protected pages, you can protect arbitrary pages by transcluding them in cascading-protected pages. This makes it equivalent to protect anyway, so there's no reason to split the rights. WONTFIX. (And I think this is also a duplicate of something, though I'm not sure which offhand).

Just ran across this again in discussion on enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(policy)#RFC:_Proposal_to_allow_Template_Editors_the_ability_to_indirectly_edit_the_Main_Page

I reject the "WONTFIX" argument that YES, editcascade can have a side affect of allowing included pages to inherit the protection - this could be desirable for some projects. More importantly, it would prevent removal or alteration of protection not needed for editing.

Chiming in at the invitation of Xaosflux. If I understand the technicalities correctly, this unbundling could address a fairly frequent matter of contention, and improve the ability of some of en.wiki's most dedicated contributors to fix serious and visible issues.

ALSO: I too reject the WONTFIX argument. If unbundled, the ability to edit cascade protected pages would be handed to a few trusted users who do not have the ability to protect pages in the normal way. If they used this user-right to bypass that restriction, it would logically be grounds for immediate removal of said user-right. Any tool is open to abuse; it is up to the community to forestall and address any such abuse.

The idea of the wontfix argument is that it's technically possible to protect any pages by editing cascade protected ones. However, while this might be theoretically true, I think there's some distinction in practice:

1. If I have an cascade protected main page, in practice I won't use this to protect anything that isn't on the main page – it would be disruptive. It's something else than doing individual protection decision.
2. You can finally combine protection levels and cascade protection in a useful way (as someone who can protect pages usually also can edit all protected pages.) This way, you could imagine a main page cascade protected to be editable just by a trusted user group (with its own protection level), while most other cascade protected pages stay on sysop level.

This isn't a purely academical topic, but has really valuable papplication in a wide variety of WMF- and Non-WMF-wikis. I really think we should do this.

Note that there's a more concrete discussion of this idea in T101309. Furthermore, there's a (hopefully still) working patch by me implementing this feature on a purely optional basis, meaning that somebody with the protect permission would still be able to edit cascade protected pages. Nothing would change if the new permission isn't explicitly designed to any goup (Currently, it's automatically assigned to sysop by default, but this could be turned of too)

@Xaosflux what's stalling this?

This has come up in a current permissions discussion with the global interface editor group, where that group has the ability to protect pages on all wikis. I do not think they should have the ability to do this.

In T71607#728172, @Jackmcbarn wrote:

If you can edit cascading-protected pages, you can protect arbitrary pages by transcluding them in cascading-protected pages. This makes it equivalent to protect anyway, so there's no reason to split the rights. WONTFIX. (And I think this is also a duplicate of something, though I'm not sure which offhand).

Not sure that this is a good perspective - perfect/enemy of good and all that.

• User-RhinosF1

This isn't something that was originally reported at Miraheze, is being managed by me nor has a significant impact for us beyond that of any mediawiki instance