Whether a (range of) logical block(s) is marked as allocated in the partition table (or in other words, part of a partition) is NOT directly related to whether it is considered as "used" / "occupied" / "mapped" (to actual storage).
It's pretty much like on filesystem level, not every logical block of a partition (or drive, if "partitionless") is deemed used either. Yet what the filesystem has keep track / record of is NOT directly related to what the firmware of the drive does either, which is why it needs to be "notified" by the OS (by the means of "TRIM") to be aware of which logical blocks can be deemed "free" (as in, the data it consists of can be considered as "forgettable").
Such notification can be triggered upon file deletion (e.g.
discard mount option in Linux, or delete notification "behavior" in Windows), periodically as per the current record in the filesystem on a partition/drive (e.g.
fstrim in Linux), or a "filesystem-neglecting" (i.e. whole partition/drive) "TRIM" (e.g.
blkdiscard in Linux).
If you have some idea about programming, you can also see logical blocks on a drive (not necessarily SSD anymore these days) as pointers. TRIM is a bit like setting a (bunch of) pointer(s) to
NULL (which is not exactly the same thing as freeing the "actual" memory either, just like TRIM does not erase a storage cell right away). A partition is nothing but a collection of logical blocks, which is in turn just a means to tell a filesystem which and how many at max it could use. (The "postition" of a logical block, or the contiguous nature of the blocks in a partition, does not reflect where/how the data is placed behind the scene.) A filesystem driver could tell the OS which of the "pointers" "allocated to" a filesystem can be set to
NULL, but the filesystem itself is not responsible of keeping records of that.
"Allocating" space as a partition in a partition table is nothing but adding a record entry to it that is composed of the zero-based addresses of a starting and ending logical block (and a few other information, of course). It does NOT tell the firmware to "set" all the blocks within the range "to
NULL". (However, in Linux many of the
mkfs utilties by default does. Not sure about Windows but AFAIK it does not trigger a full partition/drive TRIM upon formation.)
P.S. For you cloning question, different cloning software can have different cloning manner. If the software do it a in partition-by-partition manner (i.e. cloning only the partition table and all the partitions, but not the "unallocated spaces"), then it will not have problems regarding drive size as long as the "allocated"/partitioned space is not larger than the destination drive. However, it could also be doing it in a "partition-unaware" (i.e. full drive block-by-block) manner. In that case it will have problem if the destination drive size is smaller than the source. Since either of these manners will clone all the logical blocks in concern (i.e. "filesystem-unaware"), so all the corresponding blocks will be deemed "occupied" by the firmware on the destination drive regardless of whether they are so on the source drive, until you maybe run
fstrim on the destination drive. (As you might have noticed, there's not exactly a way to "get" / "read" whether a certain block "has been set to
NULL". Even if on a specific drive a block will "read zero after TRIM", it does NOT imply "read zero means TRIM'd" or "write zero is equivalent to TRIM".)