TYPO3 Core

Actually what you are seeing is not a bug but the result of changing database default values depending on wether filemetadata was/is installed. The table sys_file_metadata is provided by the core with all fields defined as optional and having NULL as a default value. So when you install TYPO3 and the first couple of files get added to the FAL you end up with a row of all NULL values in sys_file_metadata for each of the files. Now you download the SQL dump and you get your first result.

Then you install filemetadata which includes a more comprehensive version of the table sys_file_metadata which includes default values. Upon installing the extension the schema migration is performed an all existing rows which have NULL values get updated according to constraints like 'NOT NULL DEFAULT <something>'. Given you now download the SQL dump you end up with the second version, even if no new files got added.

This SQL dump will not change even when you remove the filemetadata extension in the next step and revert the schema changes. This is du to the database fields now containing a value, even if it's the previous default value. The DBMS has no safe way to revert the column values to NULL as it can't decide if it's a default value or user supplied input in there. So when you download the SQL dump after removing filemetadata you will stay with version 2 of your dump.

You can even end up with a mix of all NULL and values if you now add new files, new rows will be all NULL again.

In the end you'll always end up with what's actually stored in the database, so the dump is not broken.