DROP USER should leave no active session for that user

DROP USER deletes specified user, while there is connected session of user deleted. After deletion user is still able to select or modify data in that session. Is that a bug or designed behavior? How can I prevent deleted user from further actions in that session?

Version:11.4.2-MariaDB

Voting initiated on the page https://mariadb.org/tell-us-how-to-drop-user/ gives the result shown in the attachments section.
In according with voting results, the most popular choice on possible behavior of the statement "DROP USER" seems to be "Terminate all existing connections of the user". But note that the set of choices was not mutually exclusive. There were only three mutually exclusive choices "Keep the old behavior", "DROP USER should terminate all existing connections", "DROP USER should wait". And the third option "should wait" got the most votes. Also, most of people who thought that DROP USER should wait, also thought there should be a FORCE option.

Summing up the survey, server should do the following steps on executing the DROP USER statement:

• Server stops accepting any connections on behalf the user being dropped
• In case the option `FORCE` is NOT specified for DROP USER statement, MariaDB server is waiting until all connections established on behalf the user specified by DROP USER statement be disconnected
• The specified user is dropped
• In case the option FORCE is specified for DROP USER statement, all active connections be forcibly terminated

For support of this semantic, syntax of the statement DROP USER should be extended with the clause `FORCE`.

   DROP USER [IF EXISTS] user_name_1 [, user_name_2] ...[, user_name_N] [FORCE];

On the other hand, "wait" semantics (which should also prevent new connections by this user), while consistent with dropping of other objects, is 1) rather tricky to implement 2) has rather questionable practical usefulness, who would ever need this behavior? And if everyone will always specify FORCE, wouldn't it be better to make it the default?

Let's then implement "force" behavior, with no additional keywords.

===============================
In the final cut, this task implements the following behavior on handling DROP USER statement:

• server gets count a number of active sessions established on behalf the user being dropped
• in case the number of active session is not zero on execution of DROP USER statement,
  server
  • either throw the error ER_CANNOT_USER if sql_mode is oracle
  • or outputs the warning ER_ACTIVE_CONNECTIONS_FOR_USER_TO_DROP for sql_mode != oracle

Every user being dropped is marked with flag disallowing incoming connections on behalf itself.
In case attempt to connect a server by user being currently dropped, the error ER_CONNECT_WHILE_DROP_USER_IN_PROGRESS is output

Text messages for new error conditions thrown on handling DROP USER statement is listed below:

ER_ACTIVE_CONNECTIONS_FOR_USER_TO_DROP

        eng "Dropped users [%s] have active connections. Use KILL CONNECTION if they should not be used anymore."

ER_CONNECT_WHILE_DROP_USER_IN_PROGRESS

        eng "Attempt to make a connection on behalf the user [%s] being currently dropped"