While this would be fine to do, platform engineering is not going to work on this at this time. Ultimately, all extensions should be converted to use the extension.json mechanism.

I think there's a big misunderstanding on this bug is happening. This doesn't have anything to do with loading extension.json, actually the fact that most extensions are now being loaded with extension.json (including all of WMF-deployed ones) enabled us to file this bug.
The current status is that when you try to install with an extension enabled requiring another extension, the installer "looks" for the required extension (by checking extensions/$1/$.php and extensions/$1/extension.json) and all sorts of complex redundant logic that's already handled with ExtensionRegistry (I assume the installer code predates ExtensionRegistry). Sam's/My suggestion is to actually simplify the check logic (possibly move it to a dedicated place for b/c to remove later but first run the check the right wayTM) and by the right way I mean using ExtensionRegistry::isLoaded() (making sure the queue is empty first though) or a similar logic instead of trying to look for files and such.

HTH

@Ladsgroup thanks for explaining this, I indeed got that wrong. That sounds like something that would be nice to have.
But I guess, as with so many things, it's not a priority until it breaks something. I could move it from "icebox" to "needs volunteer"...

I will try to do it once some of my volunteer work is done, it might take a couple of months so not claiming it.

Curiously... Testing this a bit more... It seems to work as expected, locally at least

Make an extension (WikimediaMaintenance used in this example) depend on "Foo".

"requires": {
        "MediaWiki": ">= 1.35.0",
        "extensions": {
                "Foo": "*"
        }
},

Put extension "Foo" in a Folder "Bar" (so automatic attempted resolution/loading won't find it) with extension.json contents:

{
	"name": "Foo",
	"manifest_version": 2
}

I feel like I'm missing something

LocalSettings.php entry to load the extension under the other name...

wfLoadExtension( 'Foo', "$wgExtensionDirectory/Bar/extension.json" );

No error. I feel like I'm missing something obvious here

Comment out the wfLoadExtension, get ExtensionDependencyError: WikimediaMaintenance requires Foo to be installed. as expected...

Oh. Duh. It's specifically the installer doing that resolution. It works fine in normal times

Which results in these two messages being used

	"config-extension-not-found": "Could not find the registration file for the extension \"$1\"",
	"config-extension-dependency": "A dependency error was encountered while installing the extension \"$1\": $2",

In Installer::findExtensionsByType():

		while ( ( $file = readdir( $dh ) ) !== false ) {
			// skip non-dirs and hidden directories
			if ( !is_dir( "$extDir/$file" ) || $file[0] === '.' ) {
				continue;
			}
			$extStatus = $this->getExtensionInfo( $type, $directory, $file );
			if ( $extStatus->isOK() ) {
				$exts[$file] = $extStatus->value;
			} elseif ( $extStatus->hasMessage( 'config-extension-not-found' ) ) {
				// (T225512) The directory is not actually an extension. Downgrade to warning.
				$status->warning( 'config-extension-not-found', $file );
			} else {
				$status->merge( $extStatus );
			}
		}

I guess the calls to getExtensionInfo to readExtension down the tree need to downgrade the dependancy to maybe a warning (or special case it)... Then after the loop, see if the dependancies are now resolved. If they are, remove the warning/error. If they're not, escalate it and fail like before

Dependencies should follow the pattern of $wgExtensionDirectory/{name}/extension.json. Subextensions should be depended on accordingly, like Foo/Bar. The escape in the second parameter of wfLoadExtension() works mostly for legacy reasons.

Referring to T258822: Wikibase extensions do not declare extension.json dependency on Wikibase, as far as the ExtensionRegistry there is no "Wikibase" extension, just Wikibase/Client (or not because they're not using extension.json in subdirectories...).

Would Wikibase/Client work in windows?

In T263101#6778253, @Legoktm wrote:

Dependencies should follow the pattern of $wgExtensionDirectory/{name}/extension.json. Subextensions should be depended on accordingly, like Foo/Bar. The escape in the second parameter of wfLoadExtension() works mostly for legacy reasons.

As far as I can tell, MediaWiki’s incomplete support for this pattern hasn’t improved since T88434#5220888. Specifically, on Special:Version, the ConfirmEdit “subextension” FancyCaptcha still has no version information and no “credits” link.