At first blush it does appear there is potential for conflict because of how the semaphore filename template was implemented -- that's a cool find.  In practice, I wonder how often this has actually bitten anyone in the real world.  The Linux world's use of clone() (creating pid namespaces) is relatively new/young.  The BSD world's use of jails (bsd-style) take a bit of a different approach, advocate against the use of shared filesystems across jails where a similar conflict could arise, and have been around longer.

@Paul:  Out of curiosity, what inspired your discovery?

Agreed that backporting Richard's work from issue8713 does not appeal.

A few concerns:
* Retrying with a modified filename makes sense but basing it on a timestamp from the system clock is not particularly robust given that the cloned processes can be executing in sufficiently close lock step that they both get the same timestamp (given the granularity/precision of the clock functions).  Developers new to high performance computing often learn this the hard way when trying to use the system clock to create uniquely named files.
* Instead, what about using the system's available pseudo-random number generators?  Most are implemented to avoid just this problem where two or more processes/threads ask for a random/distinct value at nearly the same moment.
* What about simply using a counter (not the same static int counter but another) and incrementing it when the attempt to create the semaphore file fails?  This avoids a system function call and potentially simplifies things.  Would this be faster in the majority of cases?