In Debian 11, when I create a table using
mysql database -e "create table xyz(field1 int not null )" it gets automatically
CHARACTER SET utf8mb4,
COLLATE utf8mb4_general_ci;
BUT: if I create stored procedure the same way, for example:

SQL="DELIMITER \$\$

CREATE DEFINER = 'root'@'%'
PROCEDURE generate_npadata(IN flagv VARCHAR(1))
BEGIN
DECLARE strv varchar(7);
DECLARE done int DEFAULT FALSE;
DECLARE npanxxv varchar(7);
DECLARE statev varchar(2);
DECLARE companyv varchar(30);
DECLARE ocnv varchar(4);
END
\$\$

DELIMITER ;"

mysql database -e "${SQL}"
it gets character_set_client=latin1
collation_connection=latin1_swedish_ci

and that is a tragedy, since in this scenario, this store procedure runs 100 times slower than the same exact stored procedure, bit by bit, if the character_set_client and the collation_connection were= utf8mb4_general_ci

This should not happen. If I can do a " create table" from bash script and get
CHARACTER SET utf8mb4,
COLLATE utf8mb4_general_ci;
then I should get the same if I create any stored procedure, ceteris paribus.
I am using
Server version: 10.10.2-MariaDB-1:10.10.2+maria~deb11 mariadb.org binary distribution
Not the Debian distribution which is way behind.

This is two bugs for the price of one. The first is to make sure that a Stored Procedure gets the right character set, and the second is: even if the character set is different than the table or the database collation, that stored procedure should not run 100 times slower, and I am not exaggerating.
My stored procedure is reading from a table in a loop, and the tables can be engine=memory, it makes no difference.

I can provide root access to Helena to my development box so she can verify the facts.
Or I can send her the data and the bash script that duplicates the issue.