When do you need a new AD forest, and when do you need a new tree?
Solution 1:
.local was never a good idea and was never recommended. I'd be suspect of the other material in that book.
In the vast majority of situations, your question doesn't matter because multiple domain forests are almost never necessary anymore.
You need a new forest when you need a security boundary. A forest is a security boundary. If you require isolation of resources for legal or compliance reasons, a forest will achieve this.
You need a new child domain or tree root, well....really never. It used to be for different password policies or to reduce replication overheard or for management purposes, but really in modern AD domains this can all be achieved in a single domain scenario.
Solution 2:
Your question is overly broad, but to answer one part of it, it is possible for corp.com and newcorp.com namespaces to exist in the same forest. This is a "tree root trust" and occurs when creating a new domain tree in an existing forest, as opposed to the more common "parent-child trust" scenario where a new domain is added to an existing tree and is a child domain of a top-level root. Both trust types are two-way and transitive.
Trust Types
https://technet.microsoft.com/en-us/library/cc775736%28v=ws.10%29.aspx
To answer this question:
My biggest problem is this: What would you name your forest so that even if you add different DNS namespaces later (like adding NewCorp.com), you don't end up with a forest named Corp.com with a tree named NewCorp.com, or something even weirder?
Well, don't use the TLD for the forest root domain. Instead of contoso.com, use contosoad.contoso.com or something like that for the AD forest root namespace.
As far as general reasons for having multiple forests:
Test environments (as you already mentioned) are ideal for a separate forest. The production forests should never trust the test forests.
If one part of your company is subject to specific legal or regulatory requirements. You may not want the entire company infrastructure subject to these requirements (or your business may operate in multiple geographic areas with different or conflicting requirements), so it may be more practical to have that component of the company in a separate infrastructure, including a separate Active Directory forest.
"Shadow" forests are somewhat popular for products such as SharePoint, Lync, Office 365. There could be multiple drivers for this. You don't want to update the schema in the main production forest. You don't want to synchronize accounts with the main production forest for security reasons.
Forest recovery scenario. Although large distributed AD forest topologies are rare, if you have one, a full forest recovery scenario can be a problem. This becomes particularly acute if it is distributed globally and network bandwidth is slow or unreliable and the database is large.
Dedicated administrative forest. In large, high-security environments, it may be advisable to create a separate forest to protect highly-privileged administrative accounts to mitigate the risk of pass-the-hash attacks. For more information, see Appendix "Dedicated administrative forests" in:
Mitigating Pass-the-Hash and Other Credential Theft v2