I think this is correct behavior. 4k disks still report 512-Byte sectors at interface side. Although they internally address the sectors in 4k blocks.
The jumper is in most drives just enabling a sector-shift. On most drives it shifts the sector addressing by 1. The reason are non-4k aware OS like Winodws XP. In order to understand you need to know that Windows XP does create the first partition to start at sector 63 (yes, this is no typo).
In most cases Windows will use a file system with 4k allocation units (NTFS clusters). So you would assume that when you read an NTFS cluster from a traditional drive it just has to read 8 physical blocks. Quite simple.
Now the drive is going to use 4k sector size as well. This is entirely fine as the OS will never read smaller clusters than 4k since this is the smallest allocation unit (assuming you did not force smaller FS-clusters during format). As I wrote the drives still expose 512-Byte sectors at interface level for compatibility reason. But if you read just one single 512-Byte block, then the drive internally anyway reads a 4k-sector and then splits it to send only 512-Bytes through the cable interface.
So where is the problem now? ###
The problem with Windows XP is that as the the partition is aligned to block 63 by default. This results in a mis-alignment of NTSF clusters to physical blocks. I've created a small picture to illustrate this:
As you can see on the picture on Windows XP the logical cluster are not aligned to physical 4k-blocks. As a result if Windows reads a logical NTFS cluster it requires the drive to read two blocks, and not just one. Even worse if you just need one single NTFS cluster it reads two sectors and has to merge them in order to return only the requested data to the OS.
For write operations it's even worse. In this case the drive has to read two physical 4k sectors and then merge their contents with the contents of the new NTFS cluster before it can save back both sectors to the disk. This means instead of just replacing the sector on the HDD by overwriting it the drive has to read 8k, merge in a buffer and write 8k. This slows down write operations a lot.
In order to prevent unnecessary merging HDD manufacturers added a "compatibility" hack which can be enabled via Jumper. It's simply incrementing each 512-bytes sector address by 1. As a result the first partition created by Windows will start at sector 64 and the mapping looks as follows:
Now any read/write of a logical 4k NTFS block results in exactly reading/writing one physical sector.
Of course this work-around is not required at all if you create your partitions aligned to 4k-sector boundaries already. For example on Linux you can simply use fdisk to define at which block your partition starts. So it's a good idea to use a multiply of 8 here.
Windows is starting the first partition at sector 2048 AFAIR since Vista. So this problem does not occur here any more.
WARNING: If you still use the jumper work-around on 4k-ready OS like Vista, Win7 or Win2k8 R2 then this might actually BREAK sector alignment. The reason is that the drive will then again increment sector addresses by 1 resulting in the first partition being aligned to sector 2049 which again causes major performance drop.
So make sure if you're using a 4k-aware OS that you remove the jumper before partitioning the drive. In your specific case I think everything should be fine as long as you did re-partition the drive with the jumper removed. Formatting the drive does not have anything to do with sector alignment and 4k-addressing. The only thing you should make sure during format is that you don't use cluster sizes smaller than 4k since 2k NTFS-clusters would simply result in the requirement to still read a full 4k sector for each HDD access from the OS. By the way: Using 8k NTFS clusters is still entirely OK as the disk would simply read 2 sectors for each NTFS read/write operation.