For the hurdles section:

1. At the moment, I always load the most recent version of the Production Validator available to download from WRC. This ensures that you always have all the classes listed in the documentation. I think in the future this may not be needed but currently this is a good practice.
2. I think this a little vague but maybe on purpose because you can name that new TESTING_NAMESPACE anything you would like.
3. If you are trying to simulate differences probably the best path would be to do the optional steps of running the ConfigureNamespace and Import methods separately. This would allow you to run ConfigureNamespace to create the namespace then you could manually make changes to code to ensure there will be differences in your output after you run the Import.

For the outstanding questions:

1. BPLs are handled just fine. I have a couple in our environment and haven't run into any issues using the PV. As long as the code exists in the environment, PV doesn't care if you are running standard Rules and DTLs, BPLs, or a custom class.
2. Yes, more of this could be scripted. I believe in the last iteration of the code more of the commands needed user input. Looks like they have made a lot of good progress with this latest version so I can only imagine more will follow.

5. In order to run the complete test again where messages are completely reprocessed, you would need to delete the TESTING_NAMESPACE (whatever you called it in the ConfigureNamespace method), copy the original IRIS.DAT from your source to your folder, then start the process again. That clean up could probably be added to the documentation.

I think you should be able to use something like “%PrimaryRequestHeader.SourceConfigName” to access values in the header. I have done it in a rule but haven't tried it in a DTL but I assume it will work the same way.

Update: %PrimaryRequestHeader is defined in Ens.BusinessProcess so I'm not sure you can reference it that way in the DTL.

You can export and import the Business Partners from terminal.

To export you can use the command where FileName is a file where you want the data to be exported to. I usually save it to a .xml file.

do ##class(Ens.Config.BusinessPartner).%ExportAll(FileName)

Then you can move that file to the other server and import it using the import command. The parameters are: 

1. File to import
2. Replace anything with the same name.
3. Verbose logging
4. Delete all entries before importing.

do ##class(Ens.Conifg.BusinessPartner).%Import(FileName,1,0,1)

I'm not sure about doing it through the task menu.  I would create a custom class that extends %SYS.Task.Definition and then overwrite the OnTask method with whatever custom code you want to run. For example, if you wanted to export your Business Partners to a daily file for some reason.  You could use the method below to always pull the current date.  Once you have the new class built it will be selectable in the Task Type drop down.

Method OnTask() As %Status
    {
        set tCurDate = $ZDATE($H,8)
        do ##class(Ens.Config.BusinessParnter).%ExportAll("C:\TEST\"_tCurDate_"BusinessParnters.xml")
        Quit $$$OK
    }