At the moment we're measuring the fiber profile from the data, but one could imagine generating it from the known NevenPsf and DetectorMap.

That would be great, avoiding the need for even/odd flats, but I'm not convinced that it'd work well enough. The comparison would be very interesting, though.

As Paul knows, we should integrate the location of the traces with the detector map, even if we don't measure the profiles that way

I would love to replace FiberTrace (that essentially encodes position and profile) with a new FiberProfile object (that encodes only the profile, and use the DetectorMap for the position). However, PfsFiberTrace is part of the datamodel, so I think I need a firm proposal first, and perhaps an improved DetectorMap.

+many. Every time we have discussed this, we have wanted to separate the trace positions from the fiber shape.

I've never pushed back on eventually replacing Andreas' code; it's a question of priorities. We'll know more once we have lots of SCR data.
Re Paul's point: I don't think we need worry about the data model (we can update it), although we do need to be careful not to break people's work flows/notebooks. I can imagine ways to providing backwards compatibility in the butler.

This is a large addition. It doesn't change the state of the pipeline, but adds potential to change it in the future. It will be used for PIPE2D-472.

Merged to master.