What's wrong?

Right now, the libm feature flag of bevy_math basically just serves to pass through the same flag to glam. It should probably cause bevy_math itself to use the libm versions of functions as well.

What should be done?

We should follow in glam's footsteps here and have a math module (or whatever) inside bevy_math which is compiled to either the platform defaults (e.g. f32::sqrt) or the libm versions (libm::sqrtf) depending on the feature flag. Then our internals would be refactored to use (for example) math::sqrt instead of f32::sqrt directly.

This is a fairly substantial undertaking, even if it is basically a trivial matter of finding things and replacing them.

Another concern that I have about this is that it's unlikely that literally all relevant math in bevy is actually self-contained in the bevy_math module (e.g. bevy_transform and bevy_color also do some math), so it seems like this is bound to be "leaky" regardless. On the other hand, this could be useful for library authors depending on bevy_math to get access to additional determinacy guarantees. See #11238 for context.