I know and I should of fixed my mistake for future members that search for a similar problem... But since the OP posted the entire output of dmesg in one of the attached files it was not necessary since all the information was provided anyway.

Most interesting replies (for me as an older generation chap)! One is never too old to learn I've told myself over the years. There is ALWAYS someone who knows more about something than I have so far learned. That's why I love LinuxQuestions!

O.K. I will use the info received to try some new approaches. Apparently there's no need to seek 'older distros', just work with what I already have in hand.

First of all, the floppy disk I had inserted into the TEAC Portable Diskette Drive was the third of a set of four floppies created by AVG as a "Bootable System Disk". That may be why the media was unreadable. I'll try with different floppies that have simple data files on them to see if they are readable.

Secondly, I am doing this investigation using my HP Mini laptop which has a 128 GB KingSpec SSD installed with a dual boot option using 1) Linux Xenial75 and 2) Windows XP SP3 as operating systems to choose from.

Will return with results for your observations. Thanks for your patience with me.

Have you tried seeing if any disks are readable using XP yet?

Floppy disks are simply a file system and if the disk is readable then it should be able to mount and be read.
I would suggest that you put the floppy into the drive, then plug the drive into the USB port. If it is powered on and has a disk in the drive before you plug in the USB then it should create a device that will show in the output of dmesg as well as being seen in /dev/. On my fedora system the gnome file manager also will automount it and display it where it can be accessed.

Michaelk also asked if you have tried to read the disk in windows XP yet, which would be another test to see if the disk itself is good.

Remember, under linux you cannot read a device that does not have the file system mounted for access.

In my experience the "high density" 1.44MB floppies could only be read on the drive used to create them.
The tracks were so close together that read fails were very common on different floppy drives.

It is possible the heads are out of alignment. Not true.

At the peak of the floppy drives before CDs became common almost all commercial software was distributed by 2.5in 1.44MB disks.

Funny, from that time I remember 3.5" as reliable, certainly beside 5.25".

I never met a drive with the heads non aligned. Perhaps if you put a tyre lever in…

They were the sdcards of their day. There was always the odd scraper drive that wrecked any disk put in, but that was quickly sorted. I had an IT contract for Paint Shakers, but the driving was awful - I was meeting myself coming back. So I gave the Mechanical guys one of my "Dodgy Disks," 3.5" floppies and they would come to the pc, insert the floppy, switch on & ring me. I could diagnose over 90% of them from the utilities on the floppy. The floppies would last for months despite the fact that every drive the floppies went into had a year's dust & junk in it.

The 5.25" were definitely worse than the 3.5", probably because you needed twice as many.
Strangely, 8" floppies (and they were very floppy) never gave any problems.

Well, I can tell you that you need to specifically mount an USB floppydrive with the sync option, which tells that files should be written directly to the floppy.
Async is not preferred because it writes the file to your mount path locally first and when you manually unmount the USB floppy drive, it then copies the files over to your floppy.
With sync, you can eject the floppy with the push button without risking loss of data.

Another annoying thing is the ticking noise when the USB floppydrive is powered up in Linux (not when connected in Windows 10), forcing you insert a floppy to get rid of that sound.

Secondly, copying files to floppy is extremely slow. In my case, it took almost 15 minutes to copy a 900 KB file.
The behaviour is that the motor spins 20 seconds doing nothing then writes data to the floppy for 5 seconds and repeat again.

Third is that (maybe I had under-voltage on my PI4) when testing like reading a 20 KB JPEG, sometimes the result appears partially corrupted, however this is not always the case so the data on floppy is actually still ok. Once you've read the image, you cannot reload it again since it is already cached on your mountfolder, so you have to unmount and remount again.

I have used a python script and a mechanical switch linked to the eject in order to unmount and disable usb port, vice versa.
A bit of pita, but it kinda works.

(Update)
If you drop the option "sync" and instead use "noatime,flush", it also writes directly to the floppy but at the speed you expected it to be.
So with those options you're gonna copy ie. a file of 900Kb in merely 20 seconds. Tested switching floppies vice versa and it works. The data is fine and opening BMP and JPEG's does not show artifacts anymore.