As long as there are people using agents that support this (i.e. mainly IE11), Browser configuration will remain semi-relevant, or at least usable. Microsoft announced IE11 will go EOL on August 17th this year, but we all know it will stick around here and there.
Concerning the filename/URL
The documentation that you referred to in your own answer, has the following code sample:
<meta name="msapplication-config" content="IEconfig.xml" />
I am assuming this is where the author of the blog article you also refer to got the name
IEconfig.xml from. However, the documentation then mentions:
Note: If a webpage does not specify a browser configuration file, IE11 automatically looks for "browserconfig.xml" in the root directory of the server. To prevent this, use an "msapplication-config" header with the content attribute to "none" (shown earlier).
So, it appears the only reason they used
IEconfig.xml in the example is that it’s not
browserconfig.xml (in which case you wouldn’t need that metadata to begin with). This reminds me of their infamous
favicon.ico, which you can also link to with markup, or just call the thing
favicon.ico and be done with it.
I don’t see any negatives in supporting it (other than having to make the thing), and it might actually be useful to some users with agents that support it.
I would, however, strongly suggest always setting up a route for
/browserconfig.xml if you decide to do so. That way, agents that support it will supposedly discover it automatically (which I generally think is bad UA practice, but there you have it), and you won’t have to pollute your markup with proprietary metadata that doesn’t mean anything to any other system.
(There might also be a minuscule performance benefit to having one, depending on how many IE11 visitors you have, and the way your server handles 404s and logging, but that’s probably more theoretical than anything.)