How does “rm” on a NTFS filesystem differs from Windows’ own implementation

That there was no proper read/write NTFS support before NTFS-3G. Initially, on a dual boot system, it was possible to write a file on an NTFS partition, but on rebooting, under Windows NT/XP, you would have to do a filesystem check to get the (meta) data on disc corrected. It was therefore common to have a VFAT partition for data exchange between Windows NT/XP and Linux, as the driver for that filesystem type did not have this limitation/problems.

Since the introduction of NFTS-3G (2006) this is no longer necessary and you can write new files and update existing ones, reboot under Windows and use those files without doing a filesystem check. (By that time I had largely dispensed with rebooting and was using Windows in virtual machines instead).

NTFS-3G runs in user space, that means that it doesn't have direct access to kernel data and routines, but has to go through system calls like any normal program (and in contrast to a kernel space (device) driver).

As for df -T, that seems to operate with Fuse and that (correctly) identifies the filesystem type as fuseblk. Fuse doesn't know anything about NTFS so it doesn't provide any deeper probing. Neither does df -T probe the disc, it just asks the filesystem driver, what type it is handling (if it could, you would not have to mount a filesystem for it to show up in df -T, in that case it could just probe the device blocks directly and make a guess).