1. Best practice is to setup Global report suite and child report suite in the same manner as all data sent on the page will be sent to all at the same time. If not set up in the same manner then it is possible that some data sent will in the wrong reports.
Obviously you will have custom reports for each site section and this will need to be taken into account, even at the implementation level.
I personally abandoned the default way to implement Adobe Analytics meaning using eVars, props and events.
For all of my projects that I have opted to use contextData variables . ContextData allows you to use any variables name convention you want and if you have cross implementation, like mobile IOS, mobile Android, Web javascript, Server side java SDK, Data insertion API , you can specify same variables names and they will be processed in the same manner.
On top of that contextData gives you a lot of flexibility in a multisuite tagging scenario. Same contextData variables can be mapped to different reports (i.e eVar report) in different report suites using processing rules. So there is no more, oh wait eVar number X is available on global report suite but not in child report suite, can't use it.
One important thing to know about contextData is that it needs to set up processing rules per report suite.
Here is how I see contextData: freedom for the developer as they do not need to care which variables names they give and freedom for person in charge to set up report suites as they can map these custom variables to any reports they wish.
1.1 Please be aware to set up to estimate traffic accordingly on global report suite. You are most likely going to get far more hits on Global that the child ones. The estimation needs to be per day, if the value inputed at the creation of the report suite is to low then it will result in latency of data processing.
2. Yes it is best practice to create once report suite per environment to not destroy data in prod with stage testing. I will even as far to add one more dev report suite where you can test any combination of data without any impact of future reporting.
3. s.account variable is part of AppMeasurement.js library. Once you have initialised and instance of the library in object s then you should be able to populate s.account (note that if you use the legacy library H.27.5 you will need to use s_account).
Each report suite that you need to specify will need to go in s.account separated by a comma.
The code should look like:
/************************** CONFIG SECTION START**************************/
s = new AppMeasurement()
//Add your Report suite ID
s.account="reportSuiteID1,reportSuiteID2,etc..."
//Instantiate Visitor ID services