You'd be getting in to the part where I mentioned in my original post that I didn't want to overwhelm you with new stuff that probably wouldn't be needed in your case.  Essentially, if you were converting a bunch of opportunities, your trigger would hit the governor limits pretty quickly because your trigger has to do 2 SOQL queries for every opportunity where probability == 100.  So if you did 10 opportunities in one go, it means 20 SOQL queries.  If you did 100 in one go, it means 200 SOQL queries, and so on.

The preferred way to "Bulkify" your trigger would be to harvest all the master records needed to build all the Master-Detail record sets in 1 SOQL query, then query all detail records "IN:" (your Master record ID set).  This becomes your second SOQL query.  Then, since you've harvested ALL the detail records you'll be needing, you'll have only done 2 SOQL queries for your 100 records instead of 200 queries.

Then you organize them ahead of time in to sets of detail records that correspond to each master record, like organizing papers into different piles.  Then once you've organized them all, you'd do the step we did with the nested for loops at the end to build out the final records that would be added to your sObject list in the correct order.

So, like the way I essentially did this in my brochure app I was telling you about, was:

map<Id,set<Parent__c>> parentSets = new map<Id,set<Parent__c>>();

map<Id,set<Child__c>> childSets = new map<Id,set<Child__c>>();

list<sObject> allObjects = new list<sObject>();

for(Opportunity op : trigger.new){

 if(my conditions for building my parent-child records is true){

   parentSets.put(op.Id,null);

   }

}

for(Parent__c parent : [select Id, other fields I'll need to make my parent records, this, that from Parent__c where Opportunity__c IN: parentSets.keySet()]){

    set<Parent__c> setInstance = parentSets.get(parent.Opportunity__c) != null ? parentSets.get(parent.Opportunity__c) : new set<Parent__c>(); //if we've already added to this set, we're loading the records we've added previously into this FOR loop instance set so that we don't overwrite what we've already added.  If nothing exists already though, then we're creating a new instance set that we can add to.

    setInstance.add(parent);

    parentSets.put(parent.Opportunity__c,setInstance);  //if you put the same key back in to the mapped set, it will just overwrite the first key and corresponding value/set with this new one.  So we're just updating what existed with more complete information.

   }

}

for(Child__c child : [select Id, other fields I'll need to make my child records, this, that from Child__c where Parent__c IN: parentSets.keySet()]){

  set<Child__c> setInstance = childSets.get(child.Parent__c) != null ? childSets.get(child.Parent__c) : new set<Parent__c>();

  setInstance.add(child);

  childSets.put(child.Parent__c,setInstance);

  }

}

//Now that we have a mapped set of "Parents" and a mapped set of "Children", we can iterate through them in for loops and build out our master detail records...

for(Parent__c parent : parentSets.get(parent.Opportunity__c) != null ? parentSets.get(parent.Opportunity__c) : new set<Parent__c>()){ //we do this "null" verification IF statement because, in the off-coincidence that there are no values in our mapped set, it will crash the trigger because there will be no values to iterate through.  So this is for the weird scenario where there happens to be no related Parent-Child records that need to be made when your trigger runs.

//put together your parent records like you originally did, setting the external ID, etc.

allObjects.add(parent);

  //Create our single external ID instance like you originally did to inject in to the child.

  for(Child__c child : childSets.get(child.Parent__c) != null ? childSets.get(child.Parent__c) : new set<Parent__c>()){

  //put together your child records like you originally did, injecting the external ID in to the "__r" lookup, etc.

  allObjects.add(child);

  }

}

Essentially, you're just doing more "FOR" loop iterations than SOQL query iterations, which is considered a best practice since SOQL queries suck up a lot more resources than for loops do.

That's my understanding anyway of why we do nested mapped for loop iterations rather than nested SOQL for loop iterations, but s_k_a, you're welcome to add to this if you feel I'm leaving anything out.

If you're unfamiliar with maps or sets, refer to the Maps, Sets, Map Methods, and Set Methods sections of your handbook.  

By the way, the reason I usually use sets when organizing my records in preperation before my FOR loop iterations, is beause, if you add two of the same record ID's to a list (as opposed to a set), it will crash your trigger during the DML update because you can't do a DML on the same two ID's at the same time.  But sets will automatically overwrite the last record you added if it's the same ID value (which is rare, but it does happen occasionally on certain types of triggers depending on how you process the records).  So I just protect myself by storing records I need to organize in sets rather than lists.  Since you're doing a strict insert, it probably wouldn't be as big of a deal, but I'm just always in the habbit of organizing records in to sets so I never have to think about it.  Then when I need to prep my records for insert/update with DML, I convert them back to lists.

I'm curious to hear though how s_k_a would do it.  That's just my method like I said, but he might have a cooler way that I'm just not aware of. :)