I was not able to create table with following table options via standard engine:
" ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci  "

Piece of python code used for Table object creation:

"
connectrow = "mysql://%s:%s@%s/%s?%s" % (user,passwd,host,db,paramrow)
engine = create_engine(connectrow)
metadata = MetaData(bind=engine)
metadata.reflect()
...
default_table_options = { u'mysql_engine': u'InnoDB', u'mysql_default charset': u'utf8', u'mysql_collate': u'utf8_unicode_ci'}
table = Table(tabname, metadata, ...<column objects skipped>...,  **default_table_options)
...
metadata.create_all()
"

Root of problem is that base sql dialect compiler places "collate" before "default charset" when building "create table" statement, so that "collate" option is silently ignored by MySQL server on table creation.

Of course, it can be fixed by rough hack, defining single table option instead of two:
u'mysql_default charset': u'utf8 collate utf8_unicode_ci'.

But this seems confusing, b/c sqlalchemy allows independent 'mysql_collate' option in Table constructor, and even tries to process it at the SQL compilation phase.
So I think this behaviour worth fixing -- either by dropping support for 'collate' statement of by more smart processing of table options by compiler.

Bug seems to be purely upstream one, but as far as I spent quite big time locating it, unfortunately I have no resources for comparing debian and upstream source code to be sure (I am very sorry for it).

Hopefully, respectful debian team will be able to escalate the issue to upstream in a most proper manner.