DataTables destroy() memory retention: diagnosing lingering event listeners and DOM references

When an application repeatedly initializes and destroys DataTables instances, the documented destroy() method is the supported teardown path. The goal is to determine how completely destroy() releases internal event handlers and DOM node references, and what diagnostic criteria separate a DataTables-side retention issue from references held by surrounding application code.

Reported behavior varies across the 1.10–1.13 line: older releases are described as leaving event handlers and jQuery data references behind after destroy(), while newer 1.13 releases are said to improve listener cleanup, though DOM references may still persist in complex layouts. These claims need verification against the specific version in use. Custom extensions, third-party integrations, and framework wrappers can also hold references that destroy() does not manage, and browser differences complicate the interpretation of heap snapshots.

Specific questions:

1. Which retained-object patterns in a post-destroy heap snapshot reliably indicate DataTables-held references rather than application-held ones?
2. What cleanup differences should be expected between 1.10.x and 1.13.x for the same repeated create/destroy cycle?
3. What checks confirm that a destroyed instance's settings objects and listeners are eligible for garbage collection before a table is re-initialized?