Thank you for taking the time to look at this.  I do agree with Guido to an extent, the ipaddress module is by far the most comprehensive and useful standard IP library I've seen in a programming language, I was surprised when I first found it's existence.  But being fairly new to Python, I assumed this was the Python way and it has been extremely useful to me as a Network Automation Engineer at my company.  One way I have always seen Python as useful is that I don't have to keep reinventing the wheel or wasting time writing code that could have already been written in a standard way, I think it's one of the many important reasons why people choose Python, because the code for what they want to do probably already exists in stdlib.  But whether this library should be in stdlib or not is beyond the scope of my PR, I think we are in the situation we are in and we should make sure the stdlib is maintained and kept up to date in the mean time.

Here are the motivations for getting this added:
FEELS INCOMPLETE: This library includes the subnet_of and supernet_of methods, they will effectively allow you to break down a network into smaller subnets (i.e. go down) or find the networks parent network (i.e. go up).  But what they are missing is finding the next closest network (i.e. go sideways) - (which reminds me, perhaps I should implement a prev_network() as well?).  It's always been a case where this library has felt incomplete as it lets you go in the up and down direction but omits the sideways direction.
IT'S COMPLICATED: Finding the next closest network is not a trivial task to do in your head and it's difficult to understand, from my experience the most efficient way of doing it is on the binary level.  When I first had a use case to do this, it took me a good amount of time trying to understand this algorithm and implement it, I'm certain there will be many people out there struggling with this and reinventing the wheel.  By adding this into the ipaddress module, we help simplify this task and improve peoples network knowledge.  A lot of users of the ipaddress module are likely to be Network Engineers who have little programming experience, they would probably not be experienced enough to implement something like this or get involved in feeding it back to the Python project.
IT'S NEEDED: Personally, I almost exclusively work with IPv4 networks and one very common use case we get is slicing up networks to use them as efficiently as possible.  For example, if I am given a network of 10.250.1.0/16 and I need to reserve a /21 for some servers within that range, I would initially just reserve at the start of the network, i.e. 10.250.1.0/21 - very simple.  But now, say someone comes along and says they want a /19 from the same network, then it's not so simple anymore.  The 10.250.1.0/21 network runs from 10.250.1.0-10.250.7.254 - you can't just take the broadcast address and add 1 to it (i.e. 10.250.8.0/19 would be invalid), the next closest /19 network is actually infact 10.250.32.0/19.  There is no way to figure this out currently in the ipaddress module, even though it is a very common practice that is done by network engineers manually.  A helpful way to illustrate this is by playing around on this VPC Subnet Builder here: https://tidalmigrations.com/subnet-builder/ - You can see a screenshot of my example below: