Thanks for the report.

The problem itself is generic, but it's most visible on Windows due to the specific upgrade process.

Here is how mysql_upgrade_service works (skipping irrelevant details):

• stop server;
• start server with skip-grant-tables;
• run mysql_upgrade;
• stop server;
• start server normally.

It runs the server with skip-grant-tables, so it doesn't need to care about valid username/password, which it has nowhere to take from.

It worked fine till recently. But starting from the following revision

revno: 4336
revision-id: sergii@pisem.net-20140806112744-qb444e3qz83564db
fixes bug: https://mariadb.atlassian.net/browse/MDEV-6535
committer: Sergei Golubchik <sergii@pisem.net>
branch nick: 10.0
timestamp: Wed 2014-08-06 13:27:44 +0200
message:
  MDEV-6535 Ordering of mysql_upgrade tasks is not optimal
  
  first update system tables, then the rest

things changed. Now mysql_upgrade starts by fixing privilege tables, which ends with FLUSH PRIVILEGES (it used to be run at the end). After that, when next steps are attempted, they can't be executed because privilege checks are back in place, while mysql_upgrade and its children don't use a valid account.

Elena Stepanova, Isn't this the same with 5.6? They also run run_sql_fix_privilege_tables() before upgrading user tables and it also includes flush privileges.

Maybe, I can check it if it helps.
But mysql_upgrade_service only exists in MariaDB, so whatever they run, I doubt it works exactly the same way. Maybe they don't rely on anonymous access but use some kind of a service account, like our deb packages do. Or maybe they don't run it at all and leave it to the user to do it manually.

Any delivery date defined?

It's fairly high priority (was Blocker, even though I've just downgraded it to Critical). Normally it means that it will be in the next 10.0 release (see http://mariadb.org/jira for the release schedule).