I thought it prudent to ensure that
 IPv6 addresses are stored in the SQL database according to 
RFC 5952 rather than a variable format 'text' string.
i.e. According to 
https://datatracker.ietf.org/doc/html/rfc5952#section-1 (Hmmm????) a single IPv6 address can be 'text' string represented in many ways;
All of the following represent the same 
IPv6 address:
-       2001:db8:0:0:1:0:0:1
 
 
-       2001:0db8:0:0:1:0:0:1
 
 
-       2001:db8::1:0:0:1
 
 
-       2001:db8::0:1:0:0:1
 
 
-       2001:0db8::1:0:0:1
 
 
-       2001:db8:0:0:1::1
 
 
-       2001:db8:0000:0:1::1
 
 
-       2001:0DB8:0:0:1::1
 
which makes checking if the
 IP address was already assigned to a Road-Warrior 'device' difficult - hence despite your dismissive 
'cosmetic' statement I perform the useful compression transformation if possible.
To determine which address should be assigned to the new Road-Warrior peer, by default 
wireguard_manager assumes that the 'server' Peer is assigned '.1', so assigns '.2' to the first 'device' Peer, then '.3' for the next and so on etc.
Originally, 
wireguard_manager simply issued a single 
SQL Count(*) request to return the number of 'device' Peers currently defined then simply added '1' to the count and used this for the new IP assignment.
However if 'device' Peers are deleted, 
wireguard_manager would potentially find the
 IP already assigned or leave gaps, so I changed to always try and maintain a contiguous range starting @ 
'.2' with no gaps.
Clearly, providing custom 'server' Peer base addresses 
> '.1' isn't currently catered for as shown in your 'bug' report.
Perhaps it is indeed prudent to start the search from the base address - in your case 
'.101' for 
IPv6, yet 
'.1' for 
IPv4 rather than 
'.101'?
...but being lazy, suppose the 
IPv6 base was '
FFFF', then it's tedious rolling over the correct subnet, but for
 IPv6  '
.101' it may make sense to start from 
'.102'
Possibly a candidate for 
wireguard_manager Beta 
v4.16b2 ?