Tom, I think you may be thinking in terms of sort dates, please correct me if I have assumed incorrectly, but by definition "between" is more concise than either "about" or "circa" imo.
Yes, I did bring Sort Dates into the picture because the SortDate controls how Dates are sorted and, I suspect, it (or its algorithm) is in play in Duplicate Search Merge comparisons. Even if the latter is not the case, I doubt very much that DSM makes use of anything other than the Start Date for Between-and or From-to or other date ranges. And it may only be looking at the year of the date because the tolerance setting is set in units of years, nothing finer. Because your justification for wanting the calculator to deliver "between-and" is based on how it helps with matching other events having a single or range date, I'm pointing out that it is no better at doing so than a single date with a modifier (about or circa) that indicates it is an approximation. In fact, "between" implies a hard-bounded range unless you additionally fuzz the bounds with "about", e.g. "Bet abt 1 Apr 1900 and abt 31 Mar 1901". For DSM, a date of 1900 and a tolerance of +/1 1 year spans that entire period and then some or set it to 0 to cover the one year.
"Abt 1900" looks a lot more concise than "Bet 1 Apr 1900 and 31 Mar 1901".
To reassert and return to my original Date Calculator wish, if I ask what age you are are and you reply "56" is is NOT logical for me to assume today is your birthday.
You can assume what you will. Maybe I rounded up from 55y 7m (as an engineer, I tend to round up) or maybe I gave you the most significant digits from my age of 56y 11m 31d (damned if I will admit to 57 until there's no escape). You could logically calculate/estimate my birth date as "Bet 21 Dec 1961 and 20 May 1963" or as "Abt 1962". If I was truthful in saying 56 and my birth certificate showed a date in the "between" range, then a tolerance of +/- 1 year will let DSM match it to "Abt 1962" but not to the "between" date if my birth date was actually in 1963 (on the assumption that it is +/- 1 year from the year of the Start Date or from the numerical value actually stored in the database SortDate field). Regardless of that assumption, I may have lied about my birth date or got it wrong, as was oft the case for people providing info to the enumerator, especially for other people in the residence.
Setting aside having the calculator compute a "between" date from a Census date and age, what I would agree with is that the calculated result should have no better resolution or accuracy than the least resolution of the two operands. Currently, the calculator appears to ignore the resolution of the Age operand and delivers the result to the resolution of the Date operand. Maybe that's the crux of your complaint. If the End Date is 2018, an Age of 56 y produces "1962" as the Start, while "20 Dec 2018" as the End results in Start of "20 Dec 1962" when it should be no more accurate than "1962" and could be reasonably expected to report "Abt 1962". It does produce "1962" from a Start of "2018" and a full resolution age of "56 y 11 m 31 d"; the date output res is governed by the date input res only.
And BTW, the date calculator supports "between" dates in that it will output one if one was entered in the other date field. So you can start with a "between" date and get one calculated from an age but the resolution may be unacceptably high.