> https://bugs.python.org/issue31359 has a better details about this issue.

Yea, the approach there is again dealing with using a newer SDK to build for an older system.

> I personally believe it's safer to link against a newer SDK and deal with the trouble of finding out what to strip out, which will be opted into implications or code paths that linking a binary against a newer SDK may provide.

Why do you believe that is safer?  Apple goes to great lengths to provide compatibility for existing applications to keep running on newer systems.  That's not to say that eventually certain APIs are deprecated and removed but Python itself makes fairly minimal demands on macOS, i.e. it pretty much does not use anything other than basic libc-style system calls.  The one obvious disadvantage is that Python apps can't take advantage of newly introduced system calls (introduced after 10.m) when running on those newer systems.  I honestly don't recall any case dating back to 10.5 or so where there have been any reported problems with running a 10.m Python on a 10.n system (as best as I can recall!).  On the other hand, trying to support weak linking and backward compatibility requires more code and significant increase in ongoing testing.  It would be a good thing to have but there is a significant cost and added risk to do so.