Setting project to Wikimedia-Site-requests, as this request is about settings / configuration of a Wikimedia website.

@SatyamMishra: In the future, please always follow https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes when requesting such site configuration changes. Thanks!

Hello @SatyamMishra, since the projects doesn't have a large number of users like enwiki, and since you want that sysops will handle the flag, wouldn't it better to create "autopatrolled" usergroup and an "only autopatrolled" protection level? Then, we can also let only autopatrolled moving the pages, editing protected page, and so on, letting sysops to handle the flag!

Please consider that only 4 users have commented on the proposal, and 3 of these in the last 50 contributions arrive in 2020, so I really don't see the need to have extendedconfirmed, which is a flag intended for projects with many active users! So, asking for extended confirmed seems a bit exaggerated (see also "Special groups on small wikis" here). Also, It's not obvious that sysadmins accept that only autopatrollers/extendedconfirmed can move pages on a small wiki, and remember that they can reject configuration changes at their discretion!
P.S. Consider also that extendedconfirmed is an automatical flag, that I can get also editing a lot on my sandbox, and then I can vandalize moving the page or on protected pages, for example. Thanks :)

Hello @Superpes15, thanks for such a swift response. To the best of my knowledge "autopatrolled" rights are primarily for checking user contributions, i.e. either new page creations or edits (where flaged reiview system is enabled). Since flagged review is not enabled on bhwiki, we have to review only new page creations. This is not much a gruelling task on bhwiki. That is why we opted for "extended confirmed" group because our purpose is not primarily concerned with patrolling pages.

Another problem with 'autopatrolled' right is that each request would have to go through sysops which we consider to avoid here by 30/500 rule. We don't wish to make every granting through sysops and minimize such interference. Also, from my experience on hiwiki (where move rights are restricted to 'autopatrolled'), I would like to point out that many people request these rights just in order to be able to move pages (which is not congruent with the basic purpose of such restriction).

The point you have mentioned about "extended confirmed" being handled by local sysops is meant to be a secondary/optional way for exceptional cases only, and if such local handling is made possible, it can be used to handle the situation which you have mentioned about lot of sandbox editing too.

Hope I have made things clear.

Uhm, I'm still not convinced that extended confirmed is the best solution, according to my previous reply, but I'm pinging some sysadmins here, so they can give us their opinions! @Urbanecm @TheresNoTime @Zabe :)

We are open to the inputs. It would be good to have opinions of more experienced persons.

I find myself agreeing with @Superpes15 — the proposal for this user group appears to be "motivated by the desire to have something that bigger wikis have rather than an actual need".
A quick review of the project's recent changes doesn't immediately strike me as one which would see any significant benefit from further limiting who can edit.

This being said, I had to rely on Google Translate to understand the linked consensus, and this often fails to capture any nuances in such proposals.
Perhaps @SatyamMishra could provide a few examples of where extended confirmed page protection would have been useful (i.e. where the current page protection levels proved to be insufficient) to help us understand the moderation challenges the local community is facing?

I appreciate a local consensus does exist, and that having to further justify your request may be frustrating — ensuring that our founding principles are upheld sometimes means that additional scrutiny needs to be applied where a configuration change would potentially limit the concept that "anyone can edit".
We really appreciate you working with us to find a solution which works for everyone :-)

@TheresNoTime, Thanks for your comment. Some recent page moves i.e. to change numerals or just indiscriminate moves to imply an obsolete script for Bhojpuri language here are a few examples (not all to mention) have prompted us to move for such a provisions/request. We cannot protect all such pages to sysop level up to move protection where pages are being targeted in indiscriminate manner. Current protection levels are only autoconfirmed (easily gained automatically) and sysop level. We need an intermediate level (and without local sysop intervention) for which automatically granted extended confirmed would be more appreciable rather than autopatrolled (for which sysop handling will be necessary).

Same problem is with Content Translation tool which has been misused to create totally machine translated articles in indiscriminate manner without further manual improvements to those articles.

@TheresNoTime, I am sorry that it appears to be "motivated by the desire to copy bigger projects" but that is not the case. This IS a small wiki and very few users are active here; where such page move vandalism or pure machine translations may remain unsupervised/undone for a very long time as these can be easily missed by global monitoring team. That's why we need some protection mechanism. Hope, you will understand.

@TheresNoTime @Superpes15 It has been over a month. If this means denial then should I open a fresh discussion for "autopatrolled" usergroup and "only autopatrolled" protection level?