As written, this is not a MediaWiki core issue: the "confirmed" group is a Wikimedia configuration.

https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php

// Confirmed can do anything autoconfirmed can.
// T213003: this should happen after all the extensions had been loaded, but
// before their extension functions in case they're relying on permissions.
array_unshift( $wgExtensionFunctions, function () {
	global $wgGroupPermissions;

	$wgGroupPermissions['confirmed'] = $wgGroupPermissions['autoconfirmed'];
	$wgGroupPermissions['confirmed']['skipcaptcha'] = true;
} );

If the request is to add a variable like $wgAutodemoteOnce with additional possibilities beyond those of https://www.mediawiki.org/wiki/Manual:$wgAutopromoteOnce , we may need a stronger use case.

What about adding the functionality by creating $wgAutoUpdateUserGroups, that includes the current $wgAutopromoteOnce

$wgAutoUpdateUserGroupsOnce = [
	'onEdit' => [
		'add' => [ // Current $wgAutopromeOnce
			'extendedconfirmed' => [ '&', // Example from enwiki's current config
				[ APCOND_EDITCOUNT, 500 ],
				[ APCOND_AGE, 30 * 86400 ], // 30 days * seconds in a day
				[ '!', [ APCOND_INGROUPS, 'sysop' ] ],
				[ '!', [ APCOND_INGROUPS, 'bot' ] ],
			],
			'autopatrolled' => [ // Example from dewikivoyage's current config
				'&',
				[ APCOND_EDITCOUNT, 200 ],
			]
		],
		'remove' => [ // New
			'confirmed' => [ '&', // Requested functionality
				[ APCOND_INGROUPS, 'autoconfirmed' ],
			]
		]
	]
]

this would require changing APCOND_INGROUPS to use User::getEffectiveGroups instead of User::getGroups, so that implicit groups such as autoconfirmed can be checked.

In T232756#5489085, @Nemo_bis wrote:

As written, this is not a MediaWiki core issue: the "confirmed" group is a Wikimedia configuration.

https://noc.wikimedia.org/conf/highlight.php?file=CommonSettings.php

// Confirmed can do anything autoconfirmed can.
// T213003: this should happen after all the extensions had been loaded, but
// before their extension functions in case they're relying on permissions.
array_unshift( $wgExtensionFunctions, function () {
	global $wgGroupPermissions;

	$wgGroupPermissions['confirmed'] = $wgGroupPermissions['autoconfirmed'];
	$wgGroupPermissions['confirmed']['skipcaptcha'] = true;
} );

If the request is to add a variable like $wgAutodemoteOnce with additional possibilities beyond those of https://www.mediawiki.org/wiki/Manual:$wgAutopromoteOnce , we may need a stronger use case.

I don't know my way around the tags here. "Wikimedia-User-management" doesn't exist, so I have no idea how to tag this.

I guess the easiest way (but not entirely automatic) would be to clone the rights of autoconfirmed to confirmed (instead of including autoconfirmed) so wgAutopromoteOnce will still add autoconfirmed once the account is eligible. Admins would have to occasionally take a look to see which accounts have both confirmed and autoconfirmed and remove confirmed.

Or maybe (don't know if this is already possible), the confirmed status could be granted for, say, one year. I've seen things like interface admin being granted with an expiration date, this would make sense for confirmed. The user would (assuming they meet the requirements after a year of editing) automatically make the transition to autoconfirmed.

Or what Danny said, obviously. That seems more flexible.

In T232756#5489313, @AlexisJazz wrote:

Or maybe (don't know if this is already possible), the confirmed status could be granted for, say, one year. I've seen things like interface admin being granted with an expiration date, this would make sense for confirmed. The user would (assuming they meet the requirements after a year of editing) automatically make the transition to autoconfirmed.

It is already possible to grant confirmed with an expiration date. When granting confirmed, I usually set the expiration just past the time until autoconfirmed, which is usually a couple of days.

In T232756#5489313, @AlexisJazz wrote:

Or maybe (don't know if this is already possible), the confirmed status could be granted for, say, one year. I've seen things like interface admin being granted with an expiration date, this would make sense for confirmed. The user would (assuming they meet the requirements after a year of editing) automatically make the transition to autoconfirmed.

It is already possible to grant confirmed with an expiration date. When granting confirmed, I usually set the expiration just past the time until autoconfirmed, which is usually a couple of days.

But, how about those with the IPBE flag and those editing via Tor?

Confirmed or auto-confirmed group has nothing to do with IPBE.

In T232756#5489907, @Calvinkulit wrote:

But, how about those with the IPBE flag and those editing via Tor?

Could you clarify?

In enwiki, those with IPBE or editing via Tor need to be active for 90 days and 100 edits.

In T232756#5490161, @Calvinkulit wrote:

In enwiki, those with IPBE or editing via Tor need to be active for 90 days and 100 edits.

That is a granting guideline, not system restriction.

In T232756#5489313, @AlexisJazz wrote:

I don't know my way around the tags here. "Wikimedia-User-management" doesn't exist, so I have no idea how to tag this.

See https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes

As @DannyS712 said, we can do that and make this settings global. (on wikis where confirmed group exists)

Also, if someone tries to grant an autoconfirmed user confirmed, the tick box next to "Confirmed" will explode and the Confirmed right will never be granted.

Or even better, split the requests for the Confirmed right into a special page. If you are already Autoconfirmed, it will just become a clicking simulator as it disables some services for you.

@Calvinkulit I appreciate your ideas and all, but that would be difficult to implement. I think creating an Abuse filter and setting it to disallow would be better in this case.

Or maybe, we can burn some parts of the COM:RFR denied confirmed requests (by autoconfirmed users) archive.

Is this currently doable by a configuration variable, @Masumrezarock100 ? If not, this is not a site request now.

This is not.