;D
As the gentleman in question, allow me my 2c.
Firstly, there is no debriefing text for a Loose ending. Sad but true.
Secondly, you can transfer information from one mission in a campaign to the next mission using the commands saveStatus, saveIdentity and saveVar. loadIdentity and loadStatus are used to recover the information: I seem to recall that the variable recovers automatically. deleteStatus does what it says on the tin.
saveVar and saveStatus work between an Intro and its mission, but only saveStatus works between the mission and its Outro. saveVar does not.
Normal variables do not transfer from anywhere to anywhere: they are specfic to the Mission, Intro or Outro in question.
In Un-Impossible Mission I used saveStatus to make the squad extracted in the Outro the same squad with the same weapons as finished the mission. (It wasn't weaponPool - which I've never tackled - although the principle is the same.) However, saveStatus proved to be a very temperamental command and it was very difficult to get it to work correctly. For example, it does not seem to record whether a unit is alive or dead. I can't remember about damage. It does convey weapon and ammo information correctly.
Should anybody want to dig though
Un-Impossible Mission, which is now in Pending in the Missions Depot, they are very welcome to do so. The relevant files are
transfer.sqs, which is called shortly before the end of the mission;
exit.sqs which is launched automatically at the end of a mission, rather like init.sqs at the beginning; and
outroStart.sqs, which is called at the start of the Outro. There may be some minor details that are handled elsewhere, I can't remember, but these three files are the essence of it.
transfer.sqs detects exactly who in the squad is alive and who is dead (it's complicated because there are two loons who may or may not have joined the squad, depending on how the mission turned out) and then gives each dead loon a peculiar magazine load.
exit.sqs does the saveStatus thing. I don't know why the stuff in transfer and exit were not combined into one file: it may or may not be significant.
outroStart.sqs does some other stuff that's needed at the start of the outro. It then has the loadStatus commands and checks to see if a unit's ammo load is the peculiar one. If so, the loon must have died in the mission and is deleted from the Outro. The player unit is also messed about with to ensure he has the corrrect ammo for the Outro. Finally, all the loons known to be alive are setDammage 0, since sometimes some of them turned up dead in the Outro. I have no idea why, and since you can't test any of this properly in the Mission Editor (since the Outro does not flow from the Mission) you can imagine what a grisly job it was getting to the bottom of what was going on.
The point is, of course, that you can use this system to transfer any information you like into the Outro. For example, if dammage is transferred (for this mission it didn't matter so I can't remember) you could use a series of gamelogics with different damage levels to transfer numbers. Even if that doesn't work, you can use ammo loadouts to do the same. grenade=1, M16=2 or whatever. First loon is units, second is tens, third is hundreds and so on. Perhaps easier to figure out how many ammo types there are and use that as a your base. Although, since the mission will then load the types, it might increase your lag very slightly. Maybe binary is best.
However, the whole thing is tremendously hard work and loadStatus is clearly not really meant to be used for Outros. So frankly I wouldn't bother.
If you do want to use this in your mission you are very welcome to do so: obviously I'd appreciate a mention. It is about the most inelegant thing I've seen in the whole of mission editing, but it works. You could of course use this idea to call a particular Outro script depending on how the mission ended.