I'd probably suggest to read this document as it has some good detail on the ELC. Pay special attention to the parts about the ELC and its free nature and also the part about all ELCs being flushed once it starts to run out of resources (this last bit is very expensive directly and indirectly)
The global part of the procedure cache will indeed hold the 2KB proc cache pages that are actively in-use by a given plan (PROCBUF), It will also hold additional free buffers and no doubt there will be some modules that perhaps do direct access to the global pool. I can't give you specifics as A) I have no way of actually checking and B) I'm not sure what SAP are really wanting to share about the very granular details in the area. You can't think of these memory pools as separate beasts, there are complexities and all kinds of synchronisations taking place internal to the memory management. For example, your 'true' sql statement cache is a defined fragment memory pool that uses pages pulled from the proc cache header pool. It doesn't actually have a explicit size but its maximum size is limited at a higher level.
The procbuf pool which sits at the server level contains trees and plans but the procbuf itself is a fairly small structure and hanging off those are the actual 2KB pages that form the plan (each procbuf may indirectly use X amount of 2KB pages).
So as a given procedure (or piece of ad-hoc sql) is optimized it'll grab the space it needs from the ELC. As the execution plan is finalized those buffers will get updated and marked as in-use from the perspective of the global pool. What I don't know for certain is whether at this point those previously free buffers in the ELC will be replaced with new free buffers from the global pool.
As a procedure is executed it may (will?) then need lava execution contexts which are also taken from the ELC.
A slight aside but 'streamlined dynamic sql' included a feature which meant these lava exec contexts were grabbed when the statement was compiled rather than when executed, this was partly to help reduce the hit on procedure cache whilst stuff is merely executing. This feature also allowed the dynamic SQL cache to in essence move to the regular statement cache. Prior to this, your dynamic sql was reusable for the lifetime of a connection but once disconnected it was lost. There have been some miscommunications about this feature in terms of it being designed to share dynamic sql statements across user ids, but this never was the case, it is there to make the dynamic sql cache persistant.
(2) ASE has two famous dbcc commands for PC: flush_elc and free_unused. Where each of these operate?
flush_elc, this does what it says on the tin, it flushes the ELC for each engine. Exactly how and what bearing this has on the next request from a given engine is a question someone else would need to answer.
free_unused, this operates on a procbuf level, it will remove all procbufs (stored procedure plans/trees, lwps, default, views, triggers, partition conditions, basically all compiled objects) that are not in use and their associated 2KB pages (I think by definition all these pages must be in in-use in the global pool?). It does not touch the sql text component of the statement cache. Any ad-hoc SQL that subsequently finds a match will compile a new lwp. dbcc purgesqlcache removes the sql text part of the statement cache along with all statement cache lwps.
FWIW, on a slightly separate note all our 15.7 servers run with TF 753 and I wouldn't run them any other way.
The fragmentation of the proc cache and not being able to find larger chunks in the global list over time is only lessened by having large allocations in the ELC (758), it delays it significantly, but it can (and demostrably will) still come back in some circumstances. With 2KB allocations only you can achieve workload profile consistency over time.
In my opinion (and this is only my opinion) the large allocation feature back in 15.0.1 (or was it 15.0.2?) was a little rushed and reactionary based on the 15 optimizer and execution engine at the time. If you can keep compilation to a minimum and taking into account the enhancements that have been added since to partially reduce the memory footprints and to shorten the compilation process, 2KB allocations are OK.