We currently have 4 files in /src which are used by the _backend_agg, _image, and _path modules:

• _backend_agg_basic_types.h
• path_converters.h
• py_adaptors.h
• py_converters.h

Additionally, we have py_converters.cpp which is only used by _image. If _path or _backend_end tries to use convert_trans_affine(), they will get a missing symbol at compile time.

The dependency tree looks like this:

During my nanobind work, I struggled to understand the grouping of these files and had several questions:

• Why is "_backend_agg_basic_types.h" named with the "backend" prefix when it is used by _path?
• Why do "path_converters" and "py_converters" end with a "converters" suffix when they implement two very different ideas?
• What is the difference between a "py_adapter" and the classes found in "_backend_agg_basic_types"?
• Why do we split _backend_agg, _image, and _path into three modules when they all use agg? There's approximately 15% duplicated agg code and 10% duplicated pybind11 code present in the three modules. Most of the duplication is between _path and _backend_agg. I understand why _image makes sense on its own.

I believe that the answer to all of these is "it's how the files have evolved over time and there hasn't been a need to change anything."

With the nanobind transition, I need to have nanobind variants of these files. I have the following options:

1. Introduce nanobind variants of the files with different names. This allows me to transition _backend_agg, _image, and _path separately.
2. Keep the files the same name and have giant #ifdef USE_NANOBIND_IMPL / #ifdef USE_PYBIND11_IMPL blocks.
3. Keep the files the same name and move everything over in one PR.

I used the first option in my nanobind-experiment branch. However, I'm not sure if the original grouping of these files still makes sense.

Are there any strong opinions? Should we re-organize these in a different way?