Hi @polarathene, I'll try to answer your questions:

Are settings for server blocks only relevant?(LetsEncrypt companion seems to insert location blocks instead of using _location file)

If you need to insert a whole new location block, you need to do it in the server context - that's where the vhost.d file comes in. If you just want to alter the generated location block, for example, to add change the proxy_cookie_domain or increase the client_max_body_size, you could add a _location file.

Adding location blocks in example.com_location would be nested blocks presumably or only for settings for including into a default location block by nginx-proxy?

You cannot nest location blocks - it's only for altering the location generated by nginx-proxy. Note that _location is included after proxy_pass, although I'm not sure how much the order of the statements matters.

Do 301 redirects and other location blocks not belong in nginx-proxy, are they advised to be handled by each separate container frontend(nginx/apache/etc) instead? If so any reason why?(while not better isolated, using nginx-proxy keeps the related configs in a consistent format and location without additional hassle of modifying various thirdparty nginx/apache configs to accommodate the inclusions), perhaps in some setups, this doesn't work well with the vhost container?

Fundamentally, I like the idea that nginx-proxy is completely separated from your business logic, like doing redirects, etc. At my company, I have one redirect container per Docker host that handles all the redirections, place holders, etc. It runs vanilla nginx which contains its own location blocks. nginx-proxy still handles the SSL for these hosts, which is really nice.

I do have one situation where I need to modify the nginx-proxy config, and as much as I hate it, I see on clear alternative. I'm not sure I want to get into why it has to be this way, but what I can say is that I mount a new site in /etc/nginx/conf.d/<config>.conf and nginx-proxy will happily pick it up and serve it as well, so this may be an option for you too.

Is there a reason that multiple files or symlinks need to be created for a container with multiple vhost values? An env var to have nginx-proxy symlink all vhost to a config wouldn't make sense?

When you say symlink, I assume you mean that when you add a special config by mounting it in the vhosts.d directory, you also need to symlink in all the other domains listed in your VIRTUAL_HOST so it will get used for them too. I have a similar problem where I would love to say SERVER_INCLUDE=/etc/nginx/custom/foo.conf and LOCATION_INCLUDE=/etc/nginx/custom/foo_location.conf or something similar. The alternative - automatically creating symlinks for each VIRTUAL_HOST, sounds impossible considering they can be any valid nginx location, including PCRE regex expressions.