All I will say is just because we aren't required to implement it in __future__ that doesn't mean we can't or shouldn't. Everything should be done to underline the tentative nature of these developments, or we risk the potential of functionality frozen because "we're already using it in production."
On the other hand, __future__ imports have never been provisional, and it was never the intent of __future__ imports to be provisional. PEP 236, which introduced __future__ imports after a vigorous debate on backward compatibility, explicitly states "fully backward- compatible additions can-- and should --be introduced without a corresponding future_statement". I think it would be very surprising if a feature introduced under a future import turned out to go away rather than become the default.