TL;DR:
So, which one of these four figures are most accurate?
Non - or all of them, depending on what controller/system/OS is used, but as well as the abstraction level one looks at. And, as usual with an evolving terminology, meaning got changed, overlaying terms were introduced and some turned them upside down.
A long story - made short:
In the beginning there was only a block, no sector (*1), and it existed on tape. Blocks had arbitrary length, much like the application liked (*2). When disk came, they were first just assigned on track level. A whole track got written at once. This was soon replaced by writing separate blocks instead. In the mainframe world, were it happened first, blocks were 2048 bytes or a half page (*3).
The term sector was used when viewing this from a media angle, while block was more about the logical view. Then again, at that time they were exchangeable. It changed when for one minis and more important micros 'redeveloped' disk storage bottom up, using sector as basic term on OS as well as application level.
This is were it gets really confusing. For various reasons, later operating systems did use disk drives with a certain physical sector size but superimposed their logical sector sie. In more lucky cases these logical sectors got again called block.
A nice example is the UCSD Pascal system for the Apple II. Since UCSD system was developed on machines with a 512 byte sector/block size, the Pascal file system for the apple II always combined two consecutive physical 256 byte sectors into one logical 512 byte block.
But this also happened the other way. The be device independent, CP/M operated with a logical sector(!) size of 128 bytes. It was the BIOS' job to turn them into disk sectors, which now got called blocks - essentially turning the terminology upside down - depending on whatever physical sector size was used. To make it even more confusing, later versions (3.0?) introduced larger sector sizes as well to cover larger storage media.
Bottom line: Sectors and blocks may or may not be the same and either may be used to describe a chunk on disk or a logical structure.
my question is how we can read those sectors (or how they are stacked) when the floppy or hd is reading data from it.
By positioning on the track, and reading the headers. Each sector is prefixed by a header with track and sector number (*4). After positioning the headers are read. If it's the wrong track, the head gets repositioned (*5), if it's the right one, headers get read until the desired sector is found.
Within a track, logical sectors can come in arbitrary order. While sectors are of course always sequential, their logical number can be ordered different. Basically any drive and OS can operate with any sequence. Though, depending on hard and software, a sector my need some time for post processing before being able to read the next. So after processing the first sector, the next header it 'sees' ma be the third, as the header of the second has already passed, forcing the OS to look for almost a full rotation.
This can be leveled by simply interleaving logical sectors on a track. So instead of putting the logical sectors 1, 2, 3, 4 into the physical (sequential) sectors 1, 2, 3, 4, They are put on the track as 1, 3, 2, 4. Now reading two (logically) consecutive sectors only need the time for 3 sectors, not a whole track time plus two. This technique is called sector skewing.
As a result, logical block made up of sectors like mentioned above may not be stored in consecutive physical sectors on a disk. Apple PASCAL for example stored the logical sectors as 0, 8, 1, 9 ... but a block was formed from sector 0 and 1, making them interleave (*6)
Bottom line: Sectors and blocks may come in any order in multiple layers of abstraction.
As said, all of your drawings may apply.
*1 - Well, in the real beginning there was the punch card :)
*2 - As assumed, some very early system did really use 80 byte blocks to make it look like punch cards!
*3 - A page is a memory page of 4096 bytes, used for virtual memory as well.
*4 - Track/sector number, or some other kind of unique ID for the block is always present. But there is/may be other meta data as well. It may include things like block keys, file numbers or alike. Presence depends much on the OS/machine used.
*5 - Yes, that is a thing. For one head position is usually tracked by counting steps, but they may get out of sync, so checking and repositoning is helpful. Also, with more and denser tracks, drive mechanics did run into mechanical issues of exact positioning, so (some) drives started to use a multi precicion aproach. The motor positioned the head roughly in the right direction, followed by a secondary mechanic for fine positioning, correcting any over or undershoot.
*6 - Let's not touch 13 sector format here :)