no, the issue here is when one program wants to bind to a specific port in the ip_local_port_range only to find out that another program was allocated that port when it had no preference and told the kernel to allocate a port for it.
if you have multiple programs attempting to explicitly use the same port you have problems, but there should be no reason for the explicitly bound ports to conflict with kernel allocated ports.
Right now ip_local_port_range is a single range of ports. This patch allows the admin of the box to tell the kernel to skip over specific ports in that range. This effectivly makes ip_local_port_range be a list of ranges rather than a single range.
the problem is that right now there _are_ no 'additional measures' that a sysadmin can take to make sure that ephemeral port requests don't get this port other than just narrowing the range of available ports to not include that port, but that can drasticly cut the number of ephemeral ports available to the system.
In the cases where I have two services that need to use the same port I add a second IP address to the interface and bind one service to each IP address. but that isn't the case that these patches are addressing.