> Therefore, if I request 2 digits of precision, I expect 2 digits in the output.

The `prec` attribute in the context refers to the total number of *significant digits* that are storable, and not to the number of digits after the decimal point.  `Decimal` is at heart a floating-point type, not a fixed-point one (though the handling of significant zeros that you note means that it's useful in fixed-point contexts too).  For typical uses you'll want `prec` to be much bigger than 2.

So the number of trailing zeros is typically determined not by `prec` but by the exponents of the operands to any given operation.  In the example you cite, the output is `2.50` because the inputs both had two digits after the point.

> the docs assert that "Decimal numbers can be represented exactly"

Sure, but for example the 0.1 in your code is not a Decimal: it's a Python float, represented under the hood in binary.  Its exact value is 0.1000000000000000055511151231257827021181583404541015625, and that can't be stored exactly in a Decimal object with only two digits of precision.

So the behaviour you identify isn't a bug: the module is following a deliberate design choice here.