Subnet Communication – Different Subnet Masks with IP Address

"Nesting" (overlapping networks) requires proxy-arp and therefore SHOULD be avoided at all costs. No enterprise router will allow such a broken configuration -- each interface/subnet must be completely independent, which means out in the real world, where real IP addresses are routed, this method of "conservation" cannot be used. (aka: nonsense) ^[*]

It SHOULD not be attempted by anyone not thoroughly versed in networking. (i.e. if you haven't been designing, setting up, and maintaining large, complex networks for a decade or more, you shouldn't even be talking about this type of damage.)

(Full disclosure)
I'm doing this exact thing in an OpenStack development environment right now. 192.168.xx.0/24 has a /29 behind one of the machines in the larger /24. That machine has to have a number of specific, non-default setting changed to pretend to be hosts within the /29 slice. (aka proxy-arp) Yes, I can add a route for the /29 on the router, but the machines in the /24 still won't be able to talk to the /29 because their larger netmask means they're link-local; I'd have to add that /29 route to all the machines in the /24 for them to work.

All-0 and All-1
Those concepts haven't had any tangible meaning in modern networking for decades. Nothing you're likely to run into on the internet makes any assumptions about network size -- everything is classless now. Yes, there used to be issues using an all-0 (or 1) subnet -- say 199.72.0.0/24 (the first subnet from 199.72.0.0/16) ^{(true story)} -- because some random system on the internet (AIX) applied class logic to the range. Nothing does that today. So, with 199.72.0.0/16, the address range is 0.0 to 255.255 -- with the those too addresses being the /16's network and broadcast addresses. Those are always the /16's network and broadcast, even if a /24 were nested with it somewhere.

The active netmask ALWAYS defines the network and broadcast. Yes, that means a nested construct has multiple broadcast addresses, but due to different netmasks, nodes within different zones (sub-network, parent-network, ...) listen to different addresses. At layer-2 (ethernet), all hosts in the same domain (eg. vlan) see the same broadcasts but the host will filter out, at layer-3, the "foreign" broadcasts, unless they're sent to the "all nodes" broadcast address of 255.255.255.255.

^{[*] ISPs wanting to conserve space like this do it via bridging, but that has it's own problems.
[*] I warned my idiot ("we know more than you") coworkers not to use 199.72.0.0/24, but they did it anyway -- putting the webdev desktops in 0.0/25. A day later came the "What. Did. I. Tell. You." after complaints from every single person about random places on the internet they simply couldn't get. That was in 1997.}

Your idea of start and end addresses will slow routing decisions down a lot, and a packet may traverse multiple routers to get to its destination; mask and compare for equality uses far fewer CPU cycles than compare for >= AND <=. More CPU cycles equals more time and more CPU load. Using a mask is fast and easy to do in either software or special hardware (ASIC). You have to remember that routers switch packets individually, and a router must make the determination which way to switch a packet for each and every packet which passes through it, and each router through which a packet travels will need to do the same thing.

How can route aggregation work with odd sized subnets? The number of Internet routes is already out of hand, and the ISPs won't advertise any IPv4 prefix longer than /24.

Your idea adds unacceptable overhead and delay to packet switching. You also need to think about so tightly restricting subnets that there is no room for growth. If you have assigned 192.168.1.1 to 192.168.1.17 for subnet 1, and each subsequent subnet is equally restrictive, what happens when a manager on subnet 1 wants to add a printer, scanner, new PC, etc. Suddenly, you need to move everyone to a new, larger subnet, and you have an unused subnet that may never have a good fit, thereby wasting those 17 addresses.

This idea doesn't really solve any problems since even doubling the number of available IPv4 addresses will not even come close to fixing the IPv4 address shortage, and it adds considerably to router overhead and real world implementation support.

Keep thinking about things, but realize that there are many, many extremely intelligent people who live, eat, breathe, and sleep this stuff, and have for many years, with no thought but how to make it work better. Everything about IP is under constant review and can be changed if a consensus decides it should be. The proof is the demise of IP classes in favor of CIDR and VLSM.