Personally, as this affects fundamental objects, I would do both. As this can be a workflow issue, my thinking is:

* Assume vast majority of users & use cases want fixed behavior (or don't particularly care), so update objects to use new/fixed behavior by default.

* Add a compatibility flag for older projects which *rely* on older behavior for *all* instances of the objects.

* Add a creation argument to the objects for those cases where people rely on the old behavior for certain situations, but also want the newer behavior for most other instances.

* Document the old versus new behavior in a help-patch subpath with comparisons.

On Aug 5, 2021, at 10:55 AM, pd-dev-request@lists.iem.at wrote:

Date: Thu, 5 Aug 2021 10:55:38 +0200
From: Max <abonnements@revolwear.com>
To: pd-dev@lists.iem.at
Subject: Re: [PD-dev] plans for next Pd release
Message-ID: <265a5773-2750-af8b-22a5-d01bdc4f6483@revolwear.com>
Content-Type: text/plain; charset=utf-8; format=flowed

On 05.08.21 03:56, Miller Puckette via Pd-dev wrote:
I'm using that as rarely as I can, so far only for bug fixes.  I don't think
a limit on numerical accuracy is exactly a bug.  I think it's nicer to most
users not to have them have to bother with specifying a compatibility
version.

Maybe make the numerical accuracy a settable variable with the current 
depth as a default? (bonus: instant bitcrusher effect)

--------
Dan Wilcox
@danomatika
danomatika.com
robotcowboy.com