I have a SanDisk 16 GB A1 Micro SD card that was running the latest Buster on My raspberry Pi 4B 4 gig. I recently put that Pi in a SmartiPi case with a brand new 7 inch touch screen and decided to start over with a fresh image. I reflashed that card with Buster using Etcher. It flashed and verified fine. Plugged it into that same Pi 4B and all I got was one long green blink and then a repeating pattern of four green blinks. Plug it into my Pi 3B+ and no activity. Redownloaded Buster and reflashed it. It flashed and verified fine but same 4 green blinks when plugged into my Pi 4B.
Formatted it with the SDCard Formater and it formatted with no errors? Correct size as near as I can tell. Same deal though, My Pi 4B and Pi 3B+ won't boot from it. I plugged it into my Pi 3B+ running Buster and it didn't mount. Unplugging it gets me a not ejected properly message, but there is no eject option in the tray? I tried to open file explorer and it immediately closes again. Just a brief flash on the screen. It then wouldn't open even after removing the drive and rebooting. Eventually after multiple tries it stayed open.
I am really confused as to why Etcher thinks its fine with no issues?
I have reflashed another SD card on that same PC, with that same Buster image, with Etcher and it boots just fine on that Pi 4B and the Pi 3B+. Same card reader writer.

I run all my Pi's from USB 3 flash drives instead of SD cards as they're faster, more reliable, and more convenient to work with. After running perfectly for many many months, I recently came in to find my PBX was dead. I assumed its ADATA flash drive was the culprit and quickly restored that morning's backup to another identical ADATA flash drive and was up and running again. Upon checking the 'bad' flash drive, I discovered it works perfectly anywhere but in any Raspberry Pi. Windows is happy with it, Etcher says it verifies properly, but Raspberry Pi's won't have anything to do with it. I've used ADATA flash drives in Raspberry Pi's for years without problems, so it's a strange failure unique to this particular unit.

Thats what got me scratching my head trying to figure out what was going on. Etcher flashed and then did the 5 minute or so verification, and found no issues. The card has failed, but for quit a while I was thinking it was just corrupted. Thats what the indications were at first. Windows always says this drive needs to be formatted regardless. The SDCard formatter didn't find any issues either?

Sounds to me like you had a bad SD card, and makes me wonder about how Etcher does it's sanity check.

If you tick the box for Etcher to verify the card, it checksums it and compares the checksum against on created while it was writing the unzipped image file.

That's what the last 5 minutes of the process is running.

I'm aware. I have not disassembled the Etcher code to see for sure what it does. It's a great tool and I use it regularly.
Regardless, at least in this case, it seems to have failed to detect a bad SD card.

Self-education is, I firmly believe, the only kind of education there is - Isaac Asimov

This was a SanDisk card I bought from a reputable retailer. It reads the correct capacity, near as I can tell. The reported formatted capacity jives with its labeled size. It could very well have a dead cell? Something went south with it.
In a Windows PC it errors out in explorer with a there is something wrong with this drive, something like that. On my Pi 3B there is no open in file manager popup. If you then unplug it you get was not ejected properly message. But there is no eject option showing in the tray. When I tried to manually open file manager it just immediately closed again. And kept doing that long after I removed the card and card reader. Even after a reboot. Eventually it went back to normal.

EDIT: It was previously in use running Buster on my PI 4B. With no issues I was aware of. It was only after I decided to reimage it for a clean install that things went south.

If you want spend your time, you may check for capacity of your SD card. There are capacity fakes underway. You may involve h2testw or F3
There is a chance, etcher just verifies the data written but not the storage cells missing? (Just a theory)

I think you're missing an important point. The devices (OP's SD card/my USB flash drive) are only failing when used in a Raspberry Pi. The devices are NOT failing when used in a PC. Consequently, Etcher is not failing to detect a bad device since the devices are NOT failing in the environment that Etcher is running in.

It's true that Etcher only verifies that portion of the SD card that the Raspbian image occupies, but that's all the Raspberry Pi sees and tries to access during the boot process, so the health of the remainder of the device is irrelevant at that point.

The failure mode seems clearly related to some very subtle difference in the way a Raspberry Pi accesses the devices compared to the way a PC accesses those devices.

In a Windows PC it errors out in explorer with a there is something wrong with this drive, something like that.

That is 100% normal and happens with all devices that contain an ext4 partition. Windows doesn't understand ext4 partitions and declares they are corrupt and require formatting. This is not an indication of a defective device and must be ignored.

In a Windows PC it errors out in explorer with a there is something wrong with this drive, something like that.

That is 100% normal and happens with all devices that contain an ext4 partition. Windows doesn't understand ext4 partitions and declares they are corrupt and require formatting. This is not an indication of a defective device and must be ignored.

You should still be able to see and access the FAT 32 Boot partition on the card on a Windows PC. I've done it in the past, making edits to the config.txt on my Windows PC. I can't do that on this card. Not anymore anyway.

You should still be able to see and access the FAT 32 Boot partition on the card on a Windows PC. I've done it in the past, making edits to the config.txt on my Windows PC. I can't do that on this card. Not anymore anyway.

If immediately after successfully writing (with verify) a Raspbian image to the SD card with Etcher you can't access the FAT partition from Windows, your issue is even stranger (after ejecting and reinserting the SD card, of course).

Diskpart sees it and lists it as 14 GB and 14 GB free. I even did a clean all on it. It completed with no error messages.
Windows file explorer shows it as USB Drive but doesn't display the size or free space. Double clicking it gets me the usual has to be formatted but then it shows a F:\ is not accessible, "This volume does not contain a recognised file system". Its not seeing the Fat32 partition.
Anyway I know I'm flogging a dead horse, it just would have been nice to know it was defective earlier on. For the longest time I was thinking it was just corrupted and could be revived.

Diskpart sees it and lists it as 14 GB and 14 GB free. I even did a clean all on it. It completed with no error messages.
Windows file explorer shows it as USB Drive but doesn't display the size or free space. Double clicking it gets me the usual has to be formatted but then it shows a F:\ is not accessible, "This volume does not contain a recognised file system". Its not seeing the Fat32 partition.
Anyway I know I'm flogging a dead horse, it just would have been nice to know it was defective earlier on. For the longest time I was thinking it was just corrupted and could be revived.

And this is immediately after running Etcher on Windows and writing a valid Raspbian image to it (with verify) and getting no errors, and then ejecting the SD card and reinserting it (before doing the above)?

Diskpart sees it and lists it as 14 GB and 14 GB free. I even did a clean all on it. It completed with no error messages.
Windows file explorer shows it as USB Drive but doesn't display the size or free space. Double clicking it gets me the usual has to be formatted but then it shows a F:\ is not accessible, "This volume does not contain a recognised file system". Its not seeing the Fat32 partition.
Anyway I know I'm flogging a dead horse, it just would have been nice to know it was defective earlier on. For the longest time I was thinking it was just corrupted and could be revived.

And this is immediately after running Etcher on Windows and writing a valid Raspbian image to it (with verify) and getting no errors, and then ejecting the SD card and reinserting it (before doing the above)?

Yes, I only resorted to Diskpart when the Pi wouldn't boot from it the second time it was flashed. It's been imaged by Etcher multiple times and verified fine each time. I just now ran Win32 disk imager and it imaged fine, no error messages anyway. However clicking "Verify Only" after it was done gets me a verification failed at sector 0.

I think you're missing an important point. The devices (OP's SD card/my USB flash drive) are only failing when used in a Raspberry Pi. The devices are NOT failing when used in a PC....The failure mode seems clearly related to some very subtle difference in the way a Raspberry Pi accesses the devices compared to the way a PC accesses those devices.

The differences is the point, I am adressing. No one really knows what happens in between a virtualized Filesystem and bare memory cells of an SD card, since there is bad memory cell mapping and wear levelling underway. The hidden secret of the memory controller is just like Raspbian's GPU blob. That's where h2testw drops in. By just doing a brute force approach of writing to every said to be available memory cell and reading back.
A symptom of failing after a certain amount of write volume as th OP states could either be a general failure cell wear out or as suspected a start of adressing not existant memory cells. Whereas etcher might follow the virtualization layer, effectively hiding the memory lack Raspbian and ext4 won't. Just a theory. I see no contradiction in your and my statements.

try to install your raspbian image on your sdcard with a linux system , like ubuntu , linux mint , or debian , you can run this OS without writing it to your harddrive .
just download and burn it on a USB key drive and launch it with the BIOS appropriate option , burn your new raspbian image on your old card , and verifiy with linux based OS .
so you are sure at 100 % !

do you have tested H2Wtest programm to you card , to be sure that is not counterfact card ??? some of them display a good capacity , but in fact they had much less real capacity ! so , if you write in the real part , no problem , but if the image is larger than the real part , it is definitely bad .