Simplification of unit_step() can be inconsistent with its definition/evaluation.

[UncombedCoconut]

Steps To Reproduce

Sage gives this paradoxical simplification:

sage: t = var('t')
sage: assume(t == 0)   
sage: simplify(unit_step(t) - unit_step(0))
-1

Expected Behavior

The expected answer above is 0. Sage documents unit_step as evaluating to 1 for all nonnegative inputs, so unit_step expressions should only simplify to 0 when the input is known to be strictly negative.
Granted -- when one is truly using unit_step as a distribution (that is, integrating against it), Sage should be allowed to ignore the edge case.

Actual Behavior

Sage is simplifying unit_step(t) to 0 anytime it can deduce t <= 0.

Additional Information

I suspect the problem could be unintended semantics here -- but I don't understand Sage internals/dependencies well enough to be sure.
Thanks!

Environment

Tested with `SageMath version 10.1, Release Date: 2023-08-20`, `Using Python 3.11.5`, on Arch Linux.

Checklist

• I have searched the existing issues for a bug report that matches the one I want to file, without success.
• I have read the documentation and troubleshoot guide

[DaveWitteMorris]

I think the problem is that (by default) simplify is performed by maxima, and maxima's convention is that the function is 0 at 0. The easiest fix would be to change our definition of unit_step to be consistent with maxima, but I'm not sure that's a good idea, especially if (has been discussed) we are thinking of moving away from using maxima as the default in the long run.

FWIW:

1. Mathematica agrees with our convention that the value is 1.
2. Maple does not seem to have this function. The related Heaviside function is undefined at 0 (like sagemath's heaviside function).
3. giac does not seem to have this function. However, it uses 1 for the value of the Heaviside function.
4. sympy does not seem to have this function. It uses the compromise value 1/2 for the Heaviside function.