What do you mean I am wrong?  I have merely re-iterated how all database engines I have worked operate.

And what you are saying is that a CHAR field in Firebird acts in the same manner as that of a VARCHAR field.  If that were the case there would be no difference in how they are used and no reason to have two different data types.  Historically, in database development CHAR fields were most often used for small string fields that would most often have a predtermined length such as a unit code whereas VARCHAR fields were used for data where that size at update was not generally known but would not exceed an expected maximum.

Second, if you as Human, can observer the effects of processes being performed in milliseconds than you must have some level of magic on your side to be able to observe such differences.

CHAR fields have always been known to be more efficient  since there is no calculations required to extend or reduce the size of the CHAR field.  This efficiency is minuscule in retrospect but it is still how most CHAR field definitions work as far as I know.  However, there is a law of diminishing returns with such efficiencies if the data being stored in such a field tends to be far smaller then the defined length.  In this latter case, then the field would be taking up unneeded space within a table row.

VARCHAR fields may have defined lengths but are dynamic up to the defined length of the field.

And I was not telling Ann anything different.

This information is also within the links that were provided to me regarding the explanation between CHAR and VARCHAR fields in the Firebird developer guide...