If I copy a bootable USB drive to another USB, will it create a duplicate bootable drive?

Simply copying the files will not make a bootable drive. It's not only the files on a USB flash drive which make it bootable, but the partition table configuration, the metadata about the organization of the drive contents, which tells a PC if it is bootable, and whether it is MBR or GPT.

As noted at cyberciti.biz:

Each disk and partition has some sort of signature and metadata/magic strings on it. The metadata used by operating system to configure disks or attach drivers and mount disks on your system.

However, you can clone the flash drive with a number of tools, such as dd, EaseUS Todo Backup, and the excellent and open source Clonezilla and Rufus. (Thanks to Alex for the reminders about dd and Rufus).

There are even electronic devices which automatically replicate flash drives.

Copying only copes with files inside formatted partitions. You won't be able to do special things necessary for the boot process like setting the boot flags, writing the boot loader, or sometimes even copying normal files into the correct spot (read: sector) in the partition and set the files' attributes/permissions. Unless you're lucky to have those things available, due to a previous boot disk creation, a formatting tool that writes the boot loader to the MBR, etc., you'll need to do more steps to make the disk bootable

Specifically when booting in BIOS mode, the BIOS looks for the first sector (MBR) to see if there's a valid boot signature 0xAA55. If yes then it loads that sector and transfer control to the boot loader in the MBR. The MBR describes the partition configuration, therefore it cannot lie inside the partition and is not what you can copy with normal tools.

Besides, since the MBR is too small to be useful, most modern boot loaders split the boot process into multiple stages, with the boot code in the MBR loads its next stage. The further intra-stages are again often put in regions outside the partitions. Some may put it in the EBR, but grub usually put its second stage in the empty area between the first partition and the MBR called the post-MBR gap. That's why if one doesn't align the partitions properly, there's no space for grub to put its boot code, resulting in embedding error

Many boot loaders like LILO or old Windows/DOS boot loaders also hard code information in the MBR, like the position of the next stage or of the system files. They don't work by reading the partition data but read some hard coded sector instead, since it'll take too much code to parse the file system which is very hard to be squeezed into tiny spaces like the MBR or post-MBR gap. Even grub supports such hard coding although it's fragile hence not recommended. That means some system files have to be at the exact location sector-wise, which you can't also achieve with a normal copy. That's the reason you see "non-movable system files" while running Windows defragmenter or shrinking file systems, which is sometimes not actually correct, because it's just that Windows is too afraid to move those files even though modern boot loaders are a lot bigger, smarter and don't care about such things.

And after all, you also need to set the boot partition as active to let the boot loader know what to boot. That has to be done by a partitioning tool or by hex editing manually, since it's also put outside the partition area.

In UEFI things are a lot easier. It knows about FAT file systems (and even more file systems on non-standard implementations), therefore boot files are stored in the EFI system partition, A.K.A ESP. The UEFI loads the *.efi applications in the ESP which will then load the operating systems.

UEFI firmware supports booting from removable storage devices such as USB flash drives. For that purpose, a removable device needs to be formatted with a FAT12, FAT16 or FAT32 file system, while a boot loader needs to be stored according to the standard ESP file hierarchy, or by providing a complete path of a boot loader to the system's boot manager.

So basically you just need to copy the *.efi file(s) to the ESP and put system files in the correct folder. However, there's still a small problem because the FAT partition containing the *.efi file must be marked as ESP in the MBR or GPT table outside the partitions, which can't be done by copying like above. In particular the partition type must be changed from 0Ch/0Bh/whatever to EFh in MBR and to C12A7328-F81F-11D2-BA4B-00A0C93EC93B in GPT, since the ESP is not actually FAT12/16/32 but an independent file system based on the FAT file system family

And there are still many other partitioning schemes like BSD disk label or APM which need to be modified differently to boot. Or the USB sticks might have been formatted without a partition table at all (AFAIK Windows does this by default), therefore making it bootable will be different. But the same limit applies: you need to modify non-partitioned areas!!!