> This can be observed by using the python 3.9.1 universal2 installer and using it on
> x86_64 Big Sur or with Rossetta 2 on arm64 Big Sur.

When not manually setting SYSTEM_VERSION_COMPAT=1,  I cannot reproduce this behavior on current Big Sur (11.1) systems, either x86_64 or arm64 systems, either with the 3.9.1 python.org universal2 installer (which was built on Big Sur with deployment target of 10.9) or by building on 11.1 with MACOSX_DEPLOYMENT_TARGET=10.15:

$ ./configure MACOSX_DEPLOYMENT_TARGET=10.15
$ make
$ ./python -m sysconfig | grep DEPLOYMENT_TARGET
	CONFIG_ARGS = "'MACOSX_DEPLOYMENT_TARGET=10.15'"
	MACOSX_DEPLOYMENT_TARGET = "10.15"
$ ./python -c "from ctypes.util import find_library; print(find_library('AppKit'))"
/System/Library/Frameworks/AppKit.framework/AppKit
$ sw_vers
ProductName:	macOS
ProductVersion:	11.1
BuildVersion:	20C69
$ uname -a
Darwin vana.local 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec  2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 x86_64

===========
$ arch
arm64
$ arch -arm64 /usr/local/bin/python3.9 -c 'import sys;print(sys.version)'
3.9.1 (v3.9.1:1e5d33e9b9, Dec  7 2020, 12:44:01)
[Clang 12.0.0 (clang-1200.0.32.27)]
$ arch -arm64 /usr/local/bin/python3.9 -c "from ctypes.util import find_library; print(find_library('AppKit'))"
/System/Library/Frameworks/AppKit.framework/AppKit
$ arch -x86_64 /usr/local/bin/python3.9 -c "from ctypes.util import find_library; print(find_library('AppKit'))"
/System/Library/Frameworks/AppKit.framework/AppKit

So, I believe that, while this is an issue when building Python on macOS 10.15 and executing on macOS 11, it is not a problem for the current python.org universal2 installers. Am I missing something?

Further, I believe this issue is essentially a duplicate of Issue42619 which has a draft (work-in-progress) PR to address this in a different way.  We should consider consolidating these issues.

Note that legacy 10.9+ x86_64-only installers *will* see the find_library() failure because they are built on macOS 10.9. A fix for Issue42619 would solve that problem for future "legacy" installers built on 10.9 (although we intend to no longer produce such installers for Python 3.10.)