I thought that was an explicit goal of Perl 6 to break compatibility once and once only

Yes.

if this is not supposed to be a production release then why even bother?

Imagine you were managing the Rakudo release process.

There are already Rakudo users and some are using it in production settings. Would you completely ignore their desire for management of breakages just because you aren't ready to make the sort of compatability promises Perl 5 makes?

Further, imagine that you thought there was a good chance you could ship a release in 2013 explicitly announced as suitable for deployment in production settings. Would you prefer to wait until after that release has been shipped before starting to discuss and develop a framework for handling breakages? Would you discuss it 3 months prior to your estimated final ship date? 6 months?

Would you do anything to support users who are writing or distributing Perl 6 modules?

Bridges to other libraries, especially CPAN, are very important. What about supporting those who are interested in completing those bridges?

The Perl 6 spec includes versioning features (for both modules and the compiler). But they are not yet implemented. Would you ignore interim measures in the hope that those features get implemented in the next few weeks?

Or should we take this is as an Indication that a Production release is imminent in the very near future and a support policy is being drafted for it?

If by "very near future" you mean this year, I think there's about zero chance of that. But I've been watching Perl 6 closely for 12 years, and to me it's obvious why some folk have begun to deploy Perl 6 in production settings (it's already sufficiently attractive, despite some big problems, most notably weak documentation and lack of stability.). cf Larry Wall's recent comment about productizing Perl 6.