Well, after much to and fro with the support team, this is now mostly resolved, but not quite, in a compliance-busting way.
I had several responses from support of "this is by design", which seems to be a standard way for 365 support to try and fob off customers with tricky problems. It isn't by design, and if it is, the design is so badly flawed it should never have made it through the approval process to get built.
If you find that items in your SubstrateHolds folder aren't being purged correctly please reference ticket number 27728613.
Everything should now be working for everyone in the world (so I was told) APART from items in the Deleted Items folder. Despite my strong objections to the contrary, apparently it really is by design that the date used to purge items from the Deleted Items folder is completely different and (effectively) arbitrary to items in ANY other folders. I've been told that I need to file a design change request including a business impact statement to get this fixed. So if you do business in the EU or anywhere else covered by ISO27001, GDPR etc. I suggest you check into this by running some tests on your own tenancy, as 365 is currently probably not doing you any favours in regards these standards/regulations.
For the Deleted Items folder, the Retention Date is stamped onto the item when it is deleted and the item is copied to Deleted Items. When the MFA processes items for the first time it stamps the current date as the retention start date, the setting you chose when configuring the policy is ignored.