Apsona already computes a distinct count. A lookup field's Count metric returns the correct number of unique values, but only when the step's retrieved fields contain nothing else. Adding any field that makes rows unique, such as Amount or Date, causes the metric to fall back to the row count.
The result is that a report can show a gift list, or it can show the number of unique donors behind that list, but not both. Users build two reports for one question
Requested behavior
A distinct count that evaluates over the full result set of the step regardless of which other fields are retrieved, and displays as a grand total and as a group subtotal rather than as a per-row value.
Applied to the example above: a report listing 38 payments with Amount, Date, and Recognition Name shows a footer value of 20 unique constituents.
Reference implementation
Salesforce's Show Unique Count in the Lightning report builder. Selected from a column's menu, appears as a grand total and per-group subtotal, leaves the detail rows intact. Salesforce caps it at three per report and excludes multi-select picklist and text area fields, so a comparable limit would be acceptable.
Scope notes
Should apply to lookup fields and to text and picklist fields, not only lookups. Should work in both single-step and multi-step reports, and should carry into export and into the visualization layer's grouping so the subtotal is available per group.
Needs a stated position on nulls. Salesforce counts blank as one unique value, SOQL COUNT_DISTINCT ignores nulls. Either is workable, but the behavior should be documented rather than discovered.
Current workaround and its cost
Either maintain two reports with duplicated filter logic, or hand-code a JavaScript calculated field using value() and rowCount() to dedupe the column. The JavaScript approach works but produces the number on every row, is undocumented for this purpose, and breaks when a column label changes.