I agree that the current implementation is wonky.  

The implementation should use linkat(2) whenever it is available, that's the only portable way to honour the follow_symlinks flag as POSIX says that the behaviour for link(2) with symbolic links is implementation defined.

From a quick experiment link(2) on Linux behaves like linkat(2) without AT_SYMLINK_FOLLOW.  On macOS link(2) behaves like linkat(2) *with* AT_SYMLINK_FOLLOW.   

That means os.link behaviour is currently different on macOS and Linux. 

I think it would be worthwhile to try to standardise the behaviour. Given the relative market sizes it I'd go for the current behaviour on Linux (with explicit tests!), even if that might not be backward compatible on macOS.

I'd also add a configure test for the behaviour of link(2) and error out when the user specifies a value for follow_symlinks that's not compatible with link(2) when linkat(2) is not available.  Or maybe only do this when the user explicitly passes in a value for this argument (make it a tri-state).

Also: note that the current macOS installers on macOS don't look at the follow_symlinks flag at all, they are build on macOS 10.9 where linkat(2) is not available (unlink macOS 10.10 or later).  That's why I noticed this problem.