As documented at wagtail/wagtail#6820, this model-level change means that upgrading to django-treebeard 4.5 will generate a new migration on models extending MP_Node. This has caused a bit of a maintenance headache for Wagtail, and I suspect that other downstream packages depending on treebeard may encounter similar issues:

• Wagtail has a dependency on django-treebeard<5.0, and contains a Page model in one of its own apps that extends MP_Node
• Someone with an existing wagtail project performs a routine pip install, installing treebeard 4.5
• The next time they run ./manage.py makemigrations, it creates an 00xx_auto_yyyymmdd migration inside the wagtail package (which will typically be somewhere in site_packages and not easily accessible to non-expert developers)
• Failure case 1: the developer continues making model changes in their project, creating migrations that reference the phantom 00xx_auto_yyyymmdd migration in their dependencies. On deploying these changes to production, the migrations fail because this migration does not exist on the live server's installation of wagtail.
• Failure case 2: the developer upgrades their development instance to the next version of wagtail, replacing the previously installed package that had the 00xx_auto_yyyymmdd migration in it. Any subsequent migrations then fail, because the 00xx_auto_yyyymmdd is part of their migration history but no longer exists.

For now, we've dealt with this by making a patch release of wagtail that pins treebeard to <4.5, and in the next feature release we'll ship the necessary migration in the wagtail package along with bumping treebeard to >=4.5,<4.6. However, relying on a narrow dependency range has its own problems, particularly if projects rely on multiple third-party packages that depend on treebeard.

This is probably more a consequence of the Django migration framework's design rather than anything treebeard is doing wrong - it's just that with treebeard being something that's likely to be fairly deep in dependency chains, migrations have unusually large consequences, even ones like this that don't make any schema-level changes. Perhaps it makes sense to adopt a policy of only making migration-requiring changes in major releases?