Currently there are 2 settings that need to be overridden to change the default (remote) extension repository:

SET custom_extension_repository = '...'
SET autoinstall_extension_repository = '...'

Having those point to different endpoint I think it's an historical artifact, and mostly used to test autoinstall and autoloading in our unittester.

Documentation do not mention autoinstall_extension_repository at all, and I think users would assume setting custom_extension_repository should download from that one both these cases:

INSTALL delta;
--- this uses custom_extension_repository
FROM 'https://some.org/file.csv';
--- this autoinstall and autoload httpfs from autoinstall_extension_repository

The proposed solution, that I think should keep flexibility when needed (e.g. testing framework) while keeping most current workflow working is using custom_extension_repository as default when autoinstall_extension_repository is not set.

Added a test, that in current DuckDB fails while INSTALLing the extension from default repo (even though custom_extension_repository had been set):

FROM read_csv('https://some.org/file.csv');
Actual result:
================================================================================
Extension Autoloading Error: An error occurred while trying to automatically install the required extension 'httpfs':
Failed to download extension "httpfs" at URL "http://extensions.duckdb.org/c837f1082a/osx_arm64/httpfs.duckdb_extension.gz" (HTTP 403)
Extension "httpfs" is an existing extension.

For more info, visit https://duckdb.org/docs/extensions/troubleshooting/?version=c837f1082a&platform=osx_arm64&extension=httpfs

Fixes also a minor mistake within an #ifdef.