Please help me understand the reasons for limitations of local.settings.json and the best practices around it

I have local.settings.json with the following defined:

```json
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "dotnet",
"StorageQueue__ConnectionString": ""
}
}
```

The reasons are:

1. Our deployment process pushes the content of local.settings.json to Azure and [I want my settings to be compatible between Windows and Linux hosts]().
2. I cannot use the following, proper hierarchical configuration:
```json
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "UseDevelopmentStorage=true",
"FUNCTIONS_WORKER_RUNTIME": "dotnet",
"StorageQueue": {
"ConnectionString": ""
}
}
}
```

because it is explicitly unsupported by the `local.settings.json` schema and apparently the host, as this causes host startup to fail with `Can't determine project language from files` and `Missing value for AzureWebJobsStorage in local.settings.json`.

However if I use the first snippet (with `StorageQueue__ConnectionString`), the queue trigger that I have bound via the following:

```csharp
[QueueTrigger("queuename", Connection = "StorageQueue__ConnectionString")]
```

causes the host to fail on startup with:

```console
Warning: Cannot find value named 'StorageQueue__ConnectionString' in local.settings.json that matches 'connection' property set on 'queueTrigger'...
...
Microsoft.Azure.WebJobs.Host: Error indexing method ''. Microsoft.Azure.WebJobs.Extensions.Storage: Storage account connection string 'AzureWebJobsStorageQueue__ConnectionString' does not exist. Make sure that it is a defined App Setting.
...
Function '' failed indexing and will be disabled.
```

The same happens if I change my queue trigger to:

```csharp
[QueueTrigger("queuename", Connection = "StorageQueue:ConnectionString")]
```

At the end of the day, therefore, the only combination that works is using : as the hierarchy separator. But that does not take into account non-Windows systems, to my mind. Yes, I know we could update our deployment process to substitute __ for : when pushing to Azure, but I would rather avoid touching said process as far as possible.

The most obvious solution would be to use `appsettings.json` as well as `local.settings.json` because the former isn't subject to the completely arbitrary limits of the latter's schema, which (I assume) would allow me to use proper hierarchical config without caring about separators - but #122 says that using both together is no longer supported... but https://github.com/Azure/azure-functions-host/issues/4761 says it is.

But when I try to use `appsettings.json` by overriding `FunctionsStartup.ConfigureAppConfiguration` (as per https://github.com/Azure/azure-functions-dotnet-extensions/pull/33), the host behaves as if the file doesn't exist - I get the same `Warning: Cannot find value named 'StorageQueue__ConnectionString' in local.settings.json that matches 'connection' property set on 'queueTrigger'` message as above. (Yes, I have ensured the file is copied to the output dir on build.)

Basically, it's a very tangled mess and I'm trying to get some clear guidance here. Please can you advise:

* Does the Azure Functions local host (`func.exe`) properly support `appsettings.json`?
* If the answer to the above is "yes", what am I doing wrong/why is this not working as I expect?
* If the answer to the first question "yes", why should I use `local.settings.json` at all when I could just use `appsettings.json`? Can I simply pretend that the `local.settings.json` that's generated on project creation does not exist, and add all my nested configuration hierarchies in `appsettings.json` instead?

Start by reproducing the configuration and queue-trigger behavior with func.exe, using the local.settings.json and appsettings.json examples in the issue and the FunctionsStartup.ConfigureAppConfiguration entry point. Document whether appsettings.json is supported, how connection names and hierarchy separators behave across hosts, and when local.settings.json remains required.

Written by the indexing model from the issue text.