It is said in the API doc that the ReprojectingFeatureCollection only reprojects the default geometry. But actually it reprojects all geometries. This leads to unwanted results.
In the ReprojectingFeatureIterator class all attributes of a feature are itterated and the geometry is reprojected if it is an instance of Geometry.
I don't know what the correct/intended behaviour is. So I can't open a PR.
Maybe the intention is to reproject all geometries. Maybe it is already used like this.
If I would know I could do a PR.
The simplest fix is to update the API and let it mention that all geometries are reprojected.
Or introduce a ReprojectingFeatureCollection.features(boolean allGeometries) method, deprecate the existing ReprojectingFeatureCollection.features() and let it call the new one with features(true). This would allow to support both ways.
But this would not help if the parent class DecoratingSimpleFeatureCollection is used generically.
How should this be handled?
The current behavior has been the same for years, and changing it would break downstream applications (e.g., GeoServer WFS) so yes, fixing the doc seem to be the sane/cautious behavior.
Adding a property to control which geometries are reprojected, off by default (if not used, the behavior is same as today) is also a good option, but I'd open a different ticket for it (improvement type) and add tests to cover the new code paths.
I've tried to manually fix the conflict in the GitHub UI... let's see if the build passes (we have now formatting checks)