Historically the most common type of PACK! is the 1-element PACK! holding a ~NULL~ antiform, that you get when a branching statement takes the branch and evaluates to null.
It's not supposed to be the case that antiforms have identity--once you make the transition from a plain form to an antiform, you lose the identity (and also, binding).
So really, every branching statement that returns a PACK!-boxed null can return the same boxed null. Easy enough optimization--it's already done like that.
I've proposed something strange though... which is that putting actions in a PACK! be how they are "blessed" as legal to assign to plain WORD
I'm hopeful that can work. But it brings up a question I've wrangled with in the past: is there any way to make this cheap-as-free?
e.g. Can a single Cell act as a proxy for an immutable array holding only itself?
The idea was scrapped for things like BLOCK!, because you'd wind up with something that had nowhere to put the index or the binding.
But when it comes to PACK! (and SPLICE!...?) the binding requirement is gone, the index requirement is gone. If the original array was at an index and seen to be one item, you'd just copy that one item out as the single Cell, and do some bit twiddling voodoo to it.
Can it work?
In order to not tax the system too much on behalf of one weird optimization, it seems like you're down two bytes from the get-go: you've got the LIFT_BYTE at ANTIFORM_0 and the KIND_BYTE at TYPE_BLOCK.
Having those two bytes chewed out, it would mean the optimization would have to be something like 64-bit only, to reclaim those two bytes from the unused 32-bits in the header (which are typically unused to allow working on 32-bit platforms). The other 3 platform pointers may all be used, because they may all contain platform pointers. So really 64-bit builds only have 32 bits total to exploit.
Would tailored optimizations like this be a great use of that 32-bit advantage? (As opposed to some cross-cutting feature that presumed to take the 32-bits out of all cells to do something more awesome)? I don't know. :-/
Is there some other way to leave the LIFT_BYTE and KIND_BYTE retain the single concent Cell's information, and yet somehow make the answer come back as PACK! without costing too much extra? 
The Cell could offer one bit for this... but it would wreck a lot of other optimizations if that bit didn't live somewhere in the LIFT_BYTE and KIND_BYTE. The LIFT_BYTE already chews out 1 bit for quasi-ness (you can be both quoted and quasi, or quoted and non-quasi) which limits us to about 127 levels of quoting. If another bit were sacrificed...let's just say it's the PACK!-bit... then we could say all PACK!s have this bit set, and we're cut down to 63-ish levels of quoting.
So then, if you have a regular PACK! it has the pack bit set...but when you clear the pack bit you see it's still an antiform with a heart that's a block. And since you can't put PACK!s in packs directly (they're antiforms, they must be lifted) you know you've got a non-optimized pack. Otherwise, you have a Cell which is the sole content of the pack.
It might seem like a problem that if you try to give back a pointer to the Cell as the content of the array, the only Cell you have in your hand has been corrupted with this pack bit. So you index into the PACK! to find something that we've established acts as a PACK!. However...this issue has already been solved for sequences, by an abstraction layer called "Arraylike". When you have an arraylike thing, you don't ask it for direct addresses of cells to operate on, you give it an index and ask it to fill a temporary Cell with the bits of what's at that index. So this would be one of those things.
Even if it could be done, this still runs afoul of a lot of the fingerprinting ideas that mask the two bytes in the header to determine its makeup. 
Just a Placeholder For Any More Thoughts
It's something to keep in mind, but more important to make sure the designs solve the problems, first.
I'm cautiously optimistic about using PACK!'d actions as the "approval" tool to do plain WORD!-assignment, but haven't done it yet, so don't know if it will actually be a good answer.