Re the details tab, how much info will be presented? Think I would still put that note on the main form along with the subform.
Compound primary keys are a valid technique but I find them cumbersome and try to avoid. If each soldier can be associated with more than one unit, then I suggest a junction table to associate soldier with units. If soldier will never be associated with more than one unit, then compound key or junction table are not relevant.
Why do you have a table for roster?
If database is to track weapon assignment why doesn't 1tblWeaponsAssigned have weapon serial numbers?
Primary entities of this db appear to be: Soldiers, Weapons, Qualification Events.
Seems to me that the weapon assignment and qualification can be handled independently. If soldier will have only one weapon of a particular class/type then it can be taken for granted that the qualification for that class/type was done with that weapon. No need to record the weapon ID in the qualification data. But then does it really matter if the qualification is associated with a specific weapon (by serial number). What if weapon is damaged/lost/stolen and must be replaced? Must soldier qualify again?
Simplest structure would be a junction table to associate events and soldiers. Form/subform arrangement would be: main form creates record in qualification events (weapon type, weapon class, weapon sight, qual type), subform creates records in junction table for each soldier selected.