While it is possible to do this via both Freemarker and XSLT (we extend both with a number of "load content" APIs that can be used to pull in any content in the repository), this is not recommended due to the dependency problems it creates. As soon as you create a derived asset (a rendition) that reads content from multiple sources, that derived asset needs to be regenerated any time any of those source assets change, yet Alfresco only tracks the dependency between the original content entered via the Web Form and the renditions that are generated as part of that Web Form submission. It's effectively a one-to-one dependency between input Web Form content and output rendition.
Now the reason for this is that in the general case it's practically impossible for Alfresco (or any system, for that matter) to know with 100% certainty which derived assets need to be regenerated for any given change in the repository. You can see this by thinking through what happens when a new job posting is added to the system - this is a new asset (so no renditions have any dependencies on it yet), yet Alfresco would need to know that the job posting listing HTML file needs to be regenerated anyway. The situation gets even more complicated when you consider that content isn't only obtainable via direct (path based) retrieval - it can also be discovered via querying. Trying to figure out whether a given change to the repository changes the output of every query ever executed by any renditioning template in the system would be prohibitively expensive (but required, if Alfresco were to correctly detect which renditions need to be regenerated for any arbitrary change in the repository).
There's also the temptation to think that you can configure the same output location for the combined "job posting listing page", meaning that any time a new job posting is created it'll overwrite the previous version to include both the previous job listings and the new one. The problem with this approach is that it creates a serialisation problem on the (shared) job posting list page. Picture two users who have both created a new job posting in their user sandbox - whoever saves first will successfully overwrite the job posting listing page and lock it, preventing whoever created the second job posting from being able to save it.
So what's the solution?
The best solution at this time is to simply punt the problem to the delivery tier, and compose "multi input" pages (such as the job posting listing page) at request time. If performance is a concern, this can be made efficient by pre-generating HTML snippets for each job listing (both the table-of-contents snippet and the body snippet) and then simply including those snippets at request time to compose the final page impression (you might use server side includes for example, or <jsp:includes> or what-have-you). This doesn't have the dependency or race condition problems described above, since it's a simple 1-to-1 mapping of input Web Form content to output renditions (which are now a larger number of snippets, rather than a small number of fully composed pages).
Cheers,
Peter