Resolv.conf(.auto) and others file/directory location

Most Packages incl. dnsmasq itself locating their *.conf file inside /var/etc and link them back to /etc/*.conf.
Same packages use their own *.d temporary directory normally located under /etc and create their temporary one at /var/etc/*.d. Thats looks reasonable.
Why not for resolv.conf(.auto).
Why not for dnsmasq's "dnsmasq.d" and "hosts" which should be "hosts.d" to be naming consistent.

Since most OpenWRT devices use flash memory, temporary or transient data typically written to /var which is a memory-backed file system in most cases. This is generally much faster than writing to flash, and, for those that care, saves flash-memory "wear".

The symlink means that you don't have to drastically alter the compile-time options or scripts that run various utilities that are expecting their config files to be in /etc/<something>

The .d in the Linux world typically refers to a directory of config files that are read in by the main config file, or by another means.

I know about flash/memory topic.
But the system should be consistent inside the build.
/var is normally linked to /tmp so everything is fine with memory/flash topic.
But why some inside /tmp and some inside /var linked to /tmp
It's an historical build issue to directly address /tmp/* instead of the original linux locations /var/*.

Personally, it bothers me that /tmp/ and /var/ are not distinct. I'm considering changing it in my builds.

I can see potential reasons for this on memory-constrained devices so one doesn't unexpectedly fill one or the other.

Yes, OpenWRT does many things in non-standard ways compared to other distros using the Linux kernel...

One of this inconsistent settings is that user (inkl. via LuCI) can configure the resolv file (default /tmp/ that dnsmasq should use and dnsmasq will do if you change it.
But the consequence is that it is never filled by netifd. The path/filename is hardcoded/compiled inside netifd.
What are these setting for ?? Why netifd not reading configuration, when updating resolv.conf file ??

No need to get me started with the lack of documentation around ubus, procd, netfid and all the rest. There aren't even decent technical descriptions of how they work. Most of what's on the wiki is wildly outdated, outright wrong, or both. The answer seems to be "read the source code" if you don't like how LuCI configures your system.

On the specific question, [Solved] Dnsmasq resolv.conf inconsitent might help

Most inconsistent paths here either stem from historical precedents or uninformed ad-hoc decisions while building features. Patches to clean these up are welcome.

They're simply distinct things. Netifd is not processing dnsmasq configuration. Netifd simply writes /tmp/ (a path that dates back to early white russian times) and dnsmasq is preconfigured to use it. LuCI exposes the option because it tries to expose all settings available for dnsmasq.

About the purpose of the setting; well it is useful if you have some other machinery supplying upstream DNS servers in a dynamic way. It is likely not needed by 99% of the users, but so are many other functions as well.

Sent an RFC series which attempts to clean up some of the inconsistencies. LuCI changes obviously need to wait until something lands in master.