The package cache holds the compiled plans and its size is controlled
by the pckcachesz database config parameter.  Not sure what you mean
by "local" vs. "global" statement cache (is this in relation to DPF?)

When another query is prepared, DB2 looks to see if the plan already
exists in the cache -- by using a byte-for-byte comparison of the SQL
statements.  (i.e. "select * from t1" <> "select * FROM t1").  If
the statements match *exactly*, DB2 will use the existing plan.

Note, many things will invalidate some/all entries in the cache, like
table changes, index changes, runstats, and "FLUSH PACKAGE CACHE
DYNAMIC"

Every statement that is executed goes into the cache.  I don't know
the specific algorithm for how the cache is maintained, but it's
almost certainly LRU-based (least-recently-used).

Yes, and yes.

Package cache is global (for the database) and packages are not flushed out
when a connection that created the package is closed. They can be used by
any application connection. If DB2 finds an (absolutely) identical SQL
statements already in cache, it will use that access plan and will not have
to calculate a new one. The text of the SQL must be identical, including
spaces, etc.

It is best to use prepared statements with parameter makers ("?") if the
predicates change from one execution to the next, so that DB2 can reuse the
package in cache. If you use literals in the predicate, each statement will
be different, and little reuse will be possible.

The size is controlled by the  PCKCACHESZ parm in the database configuration
(get db config for db-name). You can monitor package cache overflow in the
application snapshot.

This goes with other answers.
At prep time, DB2 does a "lookup" in the cache to see if statement is
there. If yes execution willhappen. If not, it is compiled and then
DB2 "inserts" it in the cache, if there is room. If not, then an LRU
algorithm is used to inser it.  It will stay there, even after a
connect reset, until DB2 needs the room.
If there's no room because all statements are servicing connections
then the cache will self extend. This will happen until the request
claims all available memory as defined in DATABASE_MEMORY parameter.
A snapshot, like db2mtrk command output, would show you the value
defined/value currently used/value high water mark.
I also believe but not quite sure as I haven't verified lately, that
DB2 will "park" the compiled statement in the application agent
private memory if all conditions stated above cannot make room for the
insertion. The idea being you should not get a no room available to
store your statement once compiled.
Reegards,  Pierre.