Manually defining a pool that does not include any statically assigned IP addresses is completely normal, and it's how we've been doing things - since at LEAST the mid 1990s when I got started in this business......
Imagine that you bought season tickets to your favorite team's home games - your seats are your seats for the entire season, even when you can't make it to one particular game. If you arrive at the statdium and someone's in your seat, what are you going to do? If you leave a static IP customer's address as part of a pool, this would be the same as if a stadium sold your seat to another person if you didn't arrive at the stadium 30 minutes before the game.....
It is best practice to ensure that your dynamic pools do not include static assigned addresses.
>>>client_1 has a fixet publioc IP address = 10.2.0.30
why not 10.2.0.2? and the next 10.2.0.3 etc. reducing consequentially the pool by one?
Case study C:
For some unspecified reason, .30 must be out of pool.
Simply change the pool:
public-pool = 10.2.0.2 - 10.2.0.29, 10.2.0.31 - 10.2.0.254
These are excellent, excellent, EXCELLENT suggestions. - especially the first one.
The "case study C" is exactly how it should be done if a "fragmented" allocation is required.