Hi,
it should also be mentioned that enhanced incremental backup comes with its own set of new issues. The metadata necessary to implement it is stored on the client in a directory enhincrdb. Various generations of DP had some unwanted impact on the client through this storage, especially when it was a lot of relatively small files. It later became a sqlite database which reduced the problems, but we don't know which version you're on. It's also crucial to exclude this directory from being backed up itself, yet this isn't happening automatically and isn't even hinted on somehow (I don't want to say it's not documented, but I didn't stumble upon any docs mentioning it at the time, either). Finally, it will go bonkers every now and then and pester your logs with messages that you have to do a Full backup before everything will get into shape again which, given you probably are running an incremental forever strategy exactly because you cannot easily schedule full backups, isn't the news you wanted to ever hear.
IMO, you use enhanced incrementals exclusively when you need them, that is, when you're doing synthetic/virtual fulls. Don't just switch them on because "enhanced" makes them sound like the clearly better choice. They come with a maintenance overhad.
BTW, I consider not picking up changes in file attributes by the normal incrementals a significant bug, at least when the platform clearly makes that known by a changing time stamp (ctime in case of Unix). Nothing that requires a side store for metadata IMHO - just make it configurable for a ctime change to pick up that file on incrementals, even when mtime (and thus, the actual content) didn't change.
Then again, if enhanced incrs would be impact-free on the client, never trigger errors and never require fulls to rebuild, just work better than classic incrs, nobody would see a reason to not use them. Getting to this state clearly is the preferred option ;)
HTH,
Andre.