Afaik, there is no reason for WB hash-to-curve when SWU hash-to-curve works, right? Also, There is only one suite listed for each curve in https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hash-to-curve-16#name-suites-for-hashing As an aside, they refer to both WB and SWU as SSWU.

There are reasons to expose the underlying map-to-curve as their hash-to-field favors expand_message_xmd for sha256 when other likely prefer expand_message_xof for blake2x, shake, merlin, etc. and even PRNGs

It seemingly follows we should remove the SWUMap and WBMap types, replace their MapToCurve methods by free methods, like

pub fn map_to_curve<C>(point: P::BaseField) -> Result<C, HashToCurveError> 
where
    C: CurveGroup,
    <C as CurveGroup>::Config: SWUConfig,
{ ... }

and

pub fn map_to_curve<C>(point: P::BaseField) -> Result<C, HashToCurveError> 
where
    C: CurveGroup,
    <C as CurveGroup>::Config: WBConfig,
{ ... }

We finally replace the MapToCurve trait by

pub trait MapToCurve: CurveGroup  {
    fn map_to_curve(<Self as CurveGroup>::BaseField) -> Self;
}

Individual curves then impl MapToCurve by invoking hashing::swu::map_to_curve or hashing::wb::map_to_curve as appropriate.

Afaik, we've no reason to output an affine point here like we currently do. In fact, we pointlessly normalize the point both before and after a cofactor multiplication right now.