what is the easiest UI for the user;
This in itself can be a very long. Here is a sample of one of our maintenance forms in our medical software. We take a different approach and use the IsDirtyChanged event to dynamically add the Save and Undo links to an action list for the end-user. You can also see how we present child information to the end-user.
- Actions - This action list is in the same place on every form in the system (we actually call them pages since we use a folder style format). This list grows with actions specific to the entry form at hand.
- Getting Started - This generally has a browse and an Add new link to help the end-user get started. These links do the same thing that the Action list does...it is just on the first page (which is a page in a PanelManager).
- MRU List - We have a persistent MRU list for every maintenance form, by logged in user, in the entire system. This is a huge feature that our users love....especially since it is persistent.
Once a record is selected for maintnenace (either a new record or existing record) then the PanelManager moves to Page two which has the editor:
You'll see that as soon as a text field is changed, the Save and Undo links automatically appear in the list. This is done by handling the IsDirtyChanged event of the BO. When we load the record, we use the FillMultpleDataTables method on the BO (refer to the docs on how to use this new method in 1.6.5) to retrieve the parent and child records in a single trip to the server...MUCH faster! You can see that there is a page tab that has Provider Numbers. In this maintnenace form, there are so many fields that we had to use a page tab, which is where the child records are presented.
You can see that they are already populted when the records is loaded...NOT when you go back and forth from page to page. Doing this when a page becomes active can work in a scenario where the data is going to be very small. But the larger the data becomes the less responsive your application becomes. Users tend to be OK with an initial loading pause, but not when they are in the middle of modifying a record. If a child record is selected or added, then a ChildFormDialog control is used to show the child form. Here is what the child form for the list on the left looks like:
The Save doesn't actually save to the database, it just checks the rules and if all is well, returns back to the parent. The Parent form is where all of the saving to the database should take place.
what works best from a technical / efficiency point of view with disconnected data
This one question could be an entire training session, and is something that we cover in our training class. The bottom line is the fewer trips to the server the better and only bring back what you need.
whether a browse dialog ever works on a child form
A browse dialog will work anywhere that you put it. I think that the issue that you are running into on this forum discussion is that this is generally not something that should be done to load a record for editing on a child. If you are using the BrowseDialog to lookup a child or foreign key record then that is perfect, but to bring back a record for editing is not good programming technique and is confusing to an end-user.
His example loads the entire detail BO at form load and then uses the SF BO.ChildAutoFilter setting to apply a filter.
This can be dangerous and is something that we see people fight all the time. There is a time and place for filters, but this is generally not the place. If you are using this technique you are bringing back more data than you need to work on. Secondly, this can present issues with you add or modify a record since the filter is dynamic. I have seen MANY issues come from this approach. You have to be very cautious in a designer environment when using a filter since you are going to be adding records and modifying records...records can start "disappearing" or "moving" on you which throws a wrench in your programming logic thus introducing bugs and "disappearing data."
Finally, as for my original question on this thread concerning using a browse dialog with a child form, Trent, are you saying you are able to get the dialog to work? I can filter it to match the records in the child table, but can't get it to position the child record pointer when it closes.
This works fine and we have this in many places in our medical software. The only reason that you record would be positioned wrong in this case would be some logic in your code moving the record pointer. Check which events you are handling and where you have logic to reload or move a record pointer. The record pointer in this case is being moved AFTER the BrowseDialog has done its work.
Final Note: Larry, I think that the training class that we have in July would be a major boost to your development cycle. We cover all of these topics and more and you can move your learning curve to the left a year or more. We have tweaked our training over time to tackle all of these types of issues so that you don't continue to churn your wheels in the muck and can get to business much faster. Just a suggestion. 
Not just for Larry, but for anyone facing these types of questions!