Several times I've been wondering why multiple [osc~] or [cos~] are drifting apart.
Now, just found it's a bug, that is known since 2015 (!) but didn't see it come up here on the forum yet:

Pd's cosine table has some small DC-offset.

Here is the pull request:
https://github.com/pure-data/pure-data/pull/106

And there the two relevant patches of this topic from the Pd-mailing-list:

demonstration of drift in FM:
test.pd

https://lists.puredata.info/pipermail/pd-list/2015-11/112204.html

workaround with symmetric and bigger cosine array and [tabosc4~]:
fm-fix.pd

https://lists.puredata.info/pipermail/pd-list/2015-11/112244.html

EDIT
And in here is another patch comparing different tables:
https://github.com/pure-data/pure-data/issues/105
This patch should be proper, as the array uses +3 samples for interpolation.

late EDIT:
since Pd 0.55 and ongoing, Pd's cosine table has changed to higher resolution and might get further changes for symmetry. See release notes and https://lists.puredata.info/pipermail/pd-dev/2024-06/023715.html

This is interesting. But surely a [hip~ 5] ought to enough to remove a DC offset. I don't understand how DC offset would cause oscillators to drift apart...???

Sorry my post might have been misleading.
@nuromantix did u read thru the topic on pd-list? https://lists.puredata.info/pipermail/pd-list/2015-11/112225.html

Asymmetric FM/PM: With the modulator's circle offset, each modulation turn moves towards one direction, not returning to it's initial point.

[hip~ 5] is not useabe on very slow modulations and has other non-linearities in amplitude or phase-smearing.

A relieable cosine table is elementary to any math using it.

Yeah, funny that they keep putting off fixing it, it seems quite an easy thing to repair. Who wants backwards compatibility to something that's broken?