Authored Links Don't Update Between Environments

We have yet to install the latest and greatest content deployment update (the so-called Infrastructure Update) but I think we've pretty much given up on content deployment ever working with the custom controls and web parts used on www.westernaustralia.com. To this end we built our new Tourism Western Australia "partners" solution on the concept of a single environment used for both editing and anonymous access--no more disconnected authoring and production.

So far so good with this solution: we've got the first of many sites out the door (www.australiassouthwest.com) and there's been no looking back despite some unrelated issues. That said, we have come across one very odd problem with authored links not updating from http://edit to https://edit to http://www. We use a reverse proxy in production and do some content rewriting to ensure any stray "edit" anchor tags are rewritten as "www" but as our remote content editors access the secure site, any content links and images created internally on http://edit forever refer back to that site. Relative links don't help in this case because SharePoint helpfully changes relative URLs to their absolute equivalent.

I've isolated the problem to the custom columns or a custom content type deriving indirectly from ArticlePage. We provision these columns and content types via features. Existing columns inherited from the base content type are updated automatically between environments by SharePoint. To top it all off, adding a new column to the existing content type works fine and links are updated correctly in that column.

I've reviewed our feature code and can't even think of a mechanism for disabling this functionality. We're using similar techniques on the westernaustralia.com site (which until recently was RTM plus a bunch of hotfixes while the partners environment was built as SP1) and have no issues in this area when moving content between out authoring and production environments.

I've come across a single technet forum post with a similar problem and the MSFT respondent suggested a case be logged with MS... I imagine we'll soon be taking that path ourselves.

[Update: We raised a case and MS got to the bottom of the problem on our behalf. Here's the solution.]