Wow... quite the discussion!!
I'll try to address comments here. For the record, I was not fond of this idea at first, but I came around to see the value, especially for novice users. And it is really important to note that my proposed solution is not intended to address every possible permutation of network conflicts... it just tries to handle the most common WAN/LAN conflict scenario that negatively affects new/novice users.
I'm not 'attached' to this, though -- if the OpenWrt community (or maybe more accurately the primary dev team) deems this to be a risky/problematic/confusing feature and it doesn't get implemented, so be it.
For this to work, I think that it needs to be on at all times until disabled. If it only runs on "first boot" it means that the feature won't be useful to many new users. Example: a new user doesn't connect a WAN at first, but sets up things like wifi and time zone or whatever, but does not change the LAN. The user llater connects WAN but has a conflict... if the detection only happens for first boot, the (novice) user may not understand why things are not working properly and they will still come to the forum with this basic question. That is what we are trying to help resolve.
I think that there would be a lot of pushback to change the default OpenWrt LAN address... in large part because it is known and well documented everywhere on the web -- well beyond the scope of OpenWrt.org. Not to say that we should live with dogma forever. But this idea of conflict detection would allow the default to remain the same while offering a (deterministic by default) alternative address if a conflict is detected.
I'll be honest that sometimes I have this feeling, too. But then I remember that we all had to learn this stuff at some point. And there are many reasons someone may use OpenWrt, even if they are a novice user. If I look back on my own progression of networking knowledge, it is clear that I had to use more advanced environments (OpenWrt, EdgeOS, Unifi, others) in order to have the features available to learn in the first place... I surely made lots of mistakes and had lots of gaps in my knowledge... but by using these platforms, I learned a ton. The idea here is to alleviate one of the common pain points that happens for new/novice users.
The logic I laid out would either use the existing default (192.168.1.1/24) or a known/default alternate (say 10.9.8.1/24 as an example), based on what is happening upstream. If there is no conflict wit the current WAN address/status, the address would not change. Therefore, it is not changing randomly on every boot. The only 'random' feature here would be if engaged by the user for a situation like the road warrior context because the upstream networks are unknown, may change frequently, and there could be several concurrent connections (cellular, wifi wan, wired wan, VPN).
That could happen. But in the default state, the DHCP issued DNS resolver would be the router to which a client is directly attached, and that resolver should theoretically not look upstream since it will (by default) have the local entry for openwrt.lan.
As I mentioned earlier, IMO the problem could very easily occur after the first boot has happened. Keep in mind -- the proposed logic is to do nothing unless there actually is a conflict.
We should always remember that people who are new to OpenWrt (and/or networking in general) may be using this platform to learn. Some people just want to have a more secure alternative than the vendor supplied firmware. Others want to extend the functionality -- sometimes with basic config changes or simple package installations that are not available in the vendor firmware. Still others want to dive in deep. Not everyone knows the internals, but they can/will learn it as needed.
I agree with @reinerotto here -- many (especially novice) users connect LAN(1) > WAN(2) and end up with a conflict. That is what we are trying to address here.
The default configuration always includes an interface called lan. This is the context for which I am proposing a solution. If the user has changed this interface, or if they have multiple LANs configured, it is probably a safe assumption that they have enough networking knowledge to understand the issue with overlapping subnets. Further, if you're dealing with multiple networks, you may have numbered them in a particular way, so we don't necessarily want to start changing those other networks.
If it is default off, it defeats the purpose of trying to help novice users get 'unstuck' with a cascaded router situation that isn't routing. Obviously this could just be an optional package instead -- maybe implemented within TravelMate or something similar for the road warriors. However, this is intended to solve the problem of the cascaded routers for the newbie.
If you mean that the ISPs themselves aren't directly issuing addresses in the 192.168.1.0/24 network -- yeah, that's not a problem. ISPs should always be using public IPs or CG-NAT. Some use the 10.0.0.0/8 range (even though they're not really supposed to), so again, no conflict. But many ISP supplied routers use this subnet. So, if a new user plugs an OpenWrt router into their ISP router (a device that may be required and may not have a bridge mode option), that is when they will see the problem.
Again, remember the proposed logic only changes things if there is actually a conflict. Otherwise it does nothing, so there is no downside to having this enabled by default, IMO.