The answer is "yes", "no", and "maybe". In other words, there is no one correct answer.
For the most part, the POST formats the g-code, and little more. As far as actual generation of toolpaths, that is typically outside the purview of the POST. The POST is mostly a means of allowing a given CAM package to deal with the idiosyncracies of the g-code (and other language) implementations on various machines. Some common operations, like toolchanges, require slightly different handling on different machines, and the POST deals with those. Inserting the M998 that is required by the Tormach toolchangers is but one example. With some CAM programs, the POST can actually control whether the final output is g-code, or something entirely different, like the proprietary language used on ShopBot CNC routers.
WHAT the POST has control over varies radically from one CAM application to another. With some, like BobCAM, the user CANNOT create a custom POST at all, but must contract with BobCAD to create one, if they don't already have what you need. Some, like VisualMill, give the user only very limited control over what can be changed, by enabling and disabling various optional features. Some, most notably HSMWorks/FusionCAM, give the user total control over pretty much everything. Some are written in proprietary scripting languages, while others, like HSMWorks/Fusion, use industry-standard javascript.
Bottom line, POST requirements will, more often than not, be different for, at a minimum, every manufacturers machines, and sometimes from machine-to-machine within a given manufacturers line. They will be radically different from one CAM system to another. And, it may even vary from one user to another on any given machine.
Regards,
Ray L.