As of this writing in mid-2024, this is fairly common behavior, though a bit unexpected. More expected would be this answer here: https://askubuntu.com/a/1019069/926756
In short, when a program copies a file from one location to another it doesn't actually do any copying itself. Instead, the program asks the operating system to read some bytes from one file, and then tells the operating system to write those bytes into another file. The operating system then lies.
When the program tells the OS to write bytes, the OS - generally - reads those bytes into a buffer and tells the program that they have been written. Unless the copy program is copying using the O_SYNC flag, this is a lie. The OS merely promises that it will try to write the bytes sometime in the future if the power doesn't go out or the disk fails or a stray cosmic particle flips a bit in the RAM.
To ensure that the bytes are actually on disk and not just in the OS buffers, the program can call the sync() functions. In essence, this is a function in the OS that does nothing until the file write buffers are empty and then returns. It sounds like your copying program is telling you how many bytes it told the OS to write, minus 1 so it can only get to 99.9999...%, and then calls sync() to make sure the write is actually on disk. Unfortunately, once it does this, it has no option now but to wait.
In the link I posted above, a similar but different problem is described. It's the same scenario except the copy command does not appear to call sync() and exits when the OS has accepted all the data into its buffers. I believe this is far more typical because the program can consider its job done - the OS knows where the file bytes are and will return them correctly to whatever program wants to read the new data back. In that example, the umount command needs to have the bytes on disk and the OS forces it to wait for the buffers to empty, so instead of the copy command hanging the umount command does.
I don't believe the basic cp command offers synchronous copies, but one could use dd with oflag=sync,dsync to do a synchronous copy, and with status=progress for realtime updates. In this manner, every block (bs=4k is "safe" but larger block sizes are faster) is written to disk syncronously, and so the % update is a more accurate representation of what bytes are actually on the final device and not just what was saved into the OS file buffers.
