The partition tables don‘t care about the data they contain, but the other direction need not be true: partition data may care about the disk and partition table they are contained in.
For example, the boot sector of FAT and NTFS file systems contains a data structure called the BIOS Parameter Block* which contains fields with data like the BIOS** drive number and so-called ‘hidden sectors’, which should contain the partition offset. If you perform a byte-wise copy of the partition to another location, the BPB may be no longer valid. Code in the boot sector and the operating system reading the partition (especially if of the DOS family) may depend on the BPB being filled correctly, so the copied file system might be unbootable or inaccessible on some implementations.
Modern, GPT-aware boot loaders and operating systems will probably not care about these two fields, though; those usually refer to partitions by their UUIDs instead of hardcoded offsets. In particular GRUB, once its core image has been successfully loaded (usually either from the gap before the first partition on an MBR-partitioned disk, or from a BIOS Boot Partition on a GPT-partitioned disk), will access all partitions without using the BPB, regardless of platform.
Nevertheless, in the general case, you cannot assume that file system data does not contain references to the particular partition on the particular disk where it resides.
There may be other problems resulting from bitwise copying; for example, the file system may contain a UUID in its partition data which after bitwise copying will obviously no longer be universally unique, which may break operating systems which assume that it is. This however does not mean you'll be prevented from accessing the partition entirely.
* Here ‘BIOS’ refers not to PC firmware stored in ROM, but to the lower-level I/O subsystem of MS-DOS and PC DOS.
** Here, however, it does refer to PC firmware, in particular to interrupt 0x13 services.