`Misc/python-config.in` ultimately becomes a Python script that prints things to stdout.  It isn't written to be a module as is.  Any work to make it one is effectively writing entirely new code to do what it does.

To keep a single source of truth for `python-config` behavior instead of having two as we do today (as doko noted in bpo-16235), while still exposing the values it provides for use from Python I suggest:

1. Get rid of the `Misc/python-config.in` python code.
2. Use `Misc/python-config.sh.in` exclusively.
3. Enhancing _that_ to be able to generate a tiny data-only `sysconfig.configure` module. 
4. Invoke `python-config.sh --generate-sysconfig-bits` during build time to generate a `sysconfig/configure.py`.

This should reduce the maintenance burden and is kinder to cross-compiliation builds (which we generally are lousy at supporting despite their importance to the world, so our bar today is merely "not regressing").


All that said, in what contexts would having anything that python-config produces today be available from sysconfig be useful?