Does there exist a native UEFI disk/partition manager

You're operating under the misapprehension that PKs are tied to ESPs; they aren't. The Secure Boot cryptographic features require that individual boot loader files be signed, but those files are stored on ordinary FAT filesystems that are themselves not signed, encrypted, or otherwise cryptographically interesting. A signed boot loader file can be moved from one partition to another and continue to work just fine, at least from a Secure Boot perspective. (Moving such a file may cause it to fail because it's been separated from critical configuration files or the like, of course, but that's another matter.)

To more directly answer the question, the EFI specification imposes no limit on the number of ESPs that may be present on a computer or on a hard disk; you could have dozens of them if you wanted to, and that would be fine from the EFI's perspective. Unfortunately, Microsoft is not so flexible; Windows officially supports just one ESP per disk (maybe per computer; I'm a bit foggy on that detail). I don't know about Windows 8, but the Windows 7 installer will flake out if it sees more than one ESP on a disk; the installation will proceed part of the way and then fail. (At least, that's what it's done in my tests.) That said, if you create a second ESP after installing Windows, Windows will continue to boot and operate correctly, at least as far as I've seen. (I can't promise that it won't misbehave if you use some particular feature, though.)

Overall, then, in a multi-boot environment, I recommend restricting yourself to one ESP. I also recommend making it rather large -- 550MiB is my usual recommendation, for assorted technical reasons having to do with rare bugs and FAT sizes. That said, if you've got an existing installation with a smaller ESP, it's probably fine to just stick with it. In either case, Linux and Windows can share a single ESP just fine. I do, however, recommend backing it up early and often -- definitely back it up before installing a new OS. Because the ESP holds your boot loaders, an accidental erasure of it will render your computer unbootable.

The UEFI boot managers reads its configuration from EFI variables (that are stored in NVRAM). Depending on the configured entries and the configured boot boot order it might very well search for a ESP on each storage device.

For example, if you have - say - 2 storage devices and for each a generic entry like

PciRoot(0x0)/Pci(0x5,0x0)    # or
PciRoot(0x0)/Pci(0x1,0x1)/Ata(1,0,0)

and they are both referenced in the boot order then the UEFI boot manager probes them both for ESPs.

Also, the UEFI specification doesn't forbid the firmware to auto-add some generic entries on each boot for each newly detected storage device. Thus, depending on your system you might end up with it auto-detecting an ESP on any detected storage device, by default.

The UEFI specification also allows the firmware to discover an ESP that doesn't use the EFI system parition GUID (C12A7328-F81F-11D2-BA4B-00A0C93EC93B). Instead it might just probe for a GPT partition with a FAT filesystem and the expected file under EFI/BOOT (e.g. BOOTX64.EFI on a x86 64 bit system):

UEFI does not impose a restriction on the number or location of System Partitions that can exist on a system. System Partitions are discovered when required by UEFI firmware by examining the partition GUID and verifying that the contents of the partition conform to the FAT file system as defined in Section 13.3.1.1. Further, UEFI implementations may allow the use of conforming FAT partitions which do not use the ESP GUID. Partition creators may prevent UEFI firmware from examining and using a specific partition by setting bit 1 of the Partition Attributes (see 5.3.3) which will exclude the partition as a potential ESP.

(UEFI specification version 2.7 errata A, Section 13.3.3 Number and Location of System Partitions, page 516)

For example, the Supermicro and Qemu UEFI firmware do this.