$MFT et al are not special file names. It belongs to a set of files (they are well-formed files) that make up the NTFS volume (they're in the volume root); I think the design is a bit poetic - the file system is made up of files contained in itself. While they are relatively regular files, the FS of course needs a way to bootstrap itself. To do that, the $MFT location is in the NTFS header. The other NTFS-internal files are found by lookups through the MFT - these files are always in the first few K of the MFT.
>To do that, the $MFT location is in the NTFS header.
Actually the "NTFS header" in itself (the first 8,192 bytes of the filesystem) is actually the $Boot file, which is indexed in the $MFT as residing on first cluster of the filesystem.
It's poetic, yes, but why? As you say, you already needs lots of special handling to be able to bootstrap. On the other hand, treating the files as actual files causes bugs like this one. So on what occasion would $MFT being a file (and not some special purpose data structure) actually be useful?
If I had to guess (And this guess may just be one of a list of reasons) it might just be to ensure the blocks that make-up the MFT are correctly marked/treated as 'used' and that the system knows which blocks the MFT is using.
I don't know tons about NTFS, but most/all file-systems have a way of marking which blocks in the system are currently in use, and which are free. This is usually some type of bitmap, and a quick google suggests that NTFS uses this approach as well. In the Ext file-systems, the bitmaps and metadata are a constant size and allocated when you create the file-system, so when you use the file-system you already know which blocks are being used by these structures, and thus utilities like a fsck can check that those blocks are correctly marked as used because it already knows which blocks should be marked.
In contrast, it doesn't appear that the MFT is a constant size, meaning that when you add files you may need to increase the size of the MFT. But obviously, since it isn't preallocated beforehand you can't guarantee there is always contiguous space to add to the MFT. This means you have to track which non-contiguous blocks are being used by the MFT - and that's what file entries do in the first place, track blocks being used by some entity. So you make a file entry representing the MFT, and then that file entry tells you which blocks make-up the MFT, ensuring that any fsck or similar utilities know which blocks are in use by the MFT. If you didn't do it this way, you'd basically just have to make a 'fake' file for the MFT in the NTFS's header/superblock and all utilities would have to parse that separately to get an accurate list of currently-in-use blocks - which would basically just be a duplication of the file-system structure already there. But of course, you would also avoid this $MFT bug, so it is what it is.
Perhaps what would have made sense was two "roots" to the file-system - the standard root, and a "NTFS hidden root". The $MFT and other various special files would be placed inside the hidden root (And some way of accessing that hidden root would be provided, in theory this shouldn't be extremely complicated and programs just reading the disk image could just parse both roots the same way, requiring basically no extra code), and the regular files go in the standard root. That likely wouldn't require much actual changing to the underlying structure (Obviously it would break stuff now, but when NTFS was created it likely wouldn't have been that big of a change) and would have (in theory) prevented these types of bugs while still retaining the advantages they got from making those things represented by files.
