> As far as I've been able to tell there is no proposed syntax in the docs specifically for
> package_data.
Right.  I’ve only found an example in d2’s own setup.cfg:

package_data =
    distutils2._backport = sysconfig.cfg
    distutils2.command = wininst*.exe
    distutils2.tests = xxmodule.c

(Note that there’s a bug in build_py or config so you can’t test this right now.)

> The docs for the resources option seems to suggest separating globs with spaces, which would
> be fine by me (wouldn't allow paths that contain spaces, but that's a bad idea anyways).
Agreed.

> I think that allowing one glob string on each line is more readable
Definitely.

> Another possibility would be to allow line breaks in the value [...]
> But that's getting a little more complex syntax-wise.
Truly!

> Agreed on getting rid of data_files--it's dangerous.
Actually the resources system redefines data_files (it was even called datafiles.py and DATAFILES at one time, and it’s still handled by install_data; I think that was a better naming scheme).  distutils-style data_files were practically unusable: System packagers were unhappy because they wanted to control the location of installed files, Python authors were unhappy because they could not access the files from their code.  I think that’s why package_data took off.

> But package_data I find very useful sometimes, and I don't think it's always wrong.
OS maintainers like the Debian project strongly disagree :)

> At the very least, it's not clear to me how the above use case is intended to be replaced.
The point of resources is that it redefines data_files and is as easy to use as package_data.  If you have for example a project named Spam with a Python package spamlib and a file in templates/log.txt, your code just needs to do this:

   from packaging.database import get_file
   with get_file('Spam', 'templates/log.txt') as fp:
      ...

When run from an uninstalled checkout, for example when developing, the file will be found in the checkout.  When run after being installed on a Debian system, the file will be found in /usr/local/share/spam/templates/log.txt.  Each Python installation can decide (through sysconfig.cfg) where to install things.