​For simh they are, but not once UNIX sees them.​

Physically 7/9-tapes were variable formatt

​ed and could have multiple 'files' on them.  UNIX reveals all of this to user (as do most OSs), so you need put in the simh 'virtual' tape format support for the size of the 'blocks' and all of the extra things that the HW supports.

But after the simh 'mounts' the 'virtual tape file' on the host when it reads the 'tape', simh strips the meta-data out and presents on the blocks to the OS. Or on write, simh takes the raw blocks, adds the simulated metadata and writes that to host file system as a 'virtual tape file.'

In the old days disks physically could also be different formats.    But the 'controller' was used to format the disk.   Each disk block included metadata that the controller used.    On DEC (and most other systems of the day), the disk controller had some way to set this up, usually with the diagnostic system.   The OS saw the disk after formatting (as we do now).   The diagnostics would have decided how big a block was etc...    DEC standardized on 512 bytes per block.

simh could have taken the approach like disks, and then 'virtual disks' would need the meta data; but could have supported all sorts of file formats (like Apollo's and Xerox's).  But the simulated disk controller would then need to handle the meta data. 

Since, most OSs just looked at disk as 'block streams' simh only needs to provide for the OS to work properly, is map a UNIX file of bytes into 512 byte blocks.   This works for most OSs.  As I said, it will not work for Aegis or any of the Xerox systems which put some of what the OS normally did in the microcode of the disk controller.   

Clem