A module with the given __future__ import could be written to expect that literals are unicode instances instead of str, and encode them appropriately when passing to modules that expect str.
Such changes might have to be reverted in Python 3, since the module might then expect character strings instead of byte strings, and then might complain when it gets byte strings (which .encode will produce). So declaring that all string literals are Unicode objects might not help in the future, contrary to what the future import suggests.
The obvious way to write code that works under -U and still works in normal Python is to .encode('charmap') every value intended to be an octet, and put 'u' in front of every string intended to be unicode. That would seem to defeat the purpose of changing the default literal type.
The not so obvious way is to change the modules/methods receiving these strings to work with either string type if that is reasonable.