I cant comment (not enough rep on this site) so I have to submit this as an answer.
1) I have successfully set up a SharePoint SSRS portal using forms authentication (FBA). The SSRS part was not hard - very straightforward actually, just perform the SSRS install as SharePoint integrated. However, the SharePoint FBA part was very painful (not difficult, just lost a lot of hair and sleep over little stuff you didnt think would be necessary and couldnt find straight answers to.)
I know that you can use Report Builder 3.0 to save to a SharePoint site. I have not tried that using the FBA SharePoint portal. I dont work at that company anymore, so I dont have access to test that either. I would think it is very possible though. The portal I set up was accessed by non-domain users, which is why I had to use FBA. I was using SharePoint 2007 and SQL Server 2008 R2.
I know the following link tells of the permissions needed for Report Builder to save to a SharePoint library: http://technet.microsoft.com/en-us/library/dd255209(v=sql.105).aspx
2) I did find a specific blog post about using Basic Authentication: http://blogs.msdn.com/b/bobmeyers/archive/2006/09/28/how-to-enable-report-builder-for-non-domain-users.aspx.
There is also an article on MS technet titled: "How to: Configure Report Builder Access"
3) Another thing that is worth trying - You can use a domain account for report viewing only, then use the ReportViewer Web service/API/webpart/etc to have a report embedded within a web application. That way, the report connects using the username/password specified, not the user viewing the application. That has worked for an application I helped work on that was exposed on a DMZ web server, but used an SSRS report that was on the internal network. In that case, the SSRS instance was a Native install. If you are using .NET - you can use Visual Studio. It already has controls built in.
The only think I dont know about in this case is the use of Report Builder. Just thought I would mention it because it might help spur some thoughts.
In the first document you list, it is clearly stated that Asynchronous Mirroring is only supported in the Enterprise Edition of SQL Server 2008.
Synchronous Mirroring is available in the Standard Edition.
Best Answer
Bjorn,
There is nothing out of the box that will force the developers to use non-deprecated features (as they are deprecated, not removed). The most tailored solution that could be created is with DDL trigger(s), but note that they can be tricky... especially if not extremely familiar with them.
I would suggest PBM, but it has limitations that won't necessarily capture everything you're looking for. As already discussed, you can use extended events (in the previous link I had) to check for the use of the deprecated items.
Here is an example that will stop the use of fn_get_sql() and give a helpful message while stopping the use. Note that multiple checks can be made in the same trigger, this is just a trivial example.
http://msdn.microsoft.com/en-us/library/ms189799.aspx
http://msdn.microsoft.com/en-us/library/ms187909.aspx
http://msdn.microsoft.com/en-us/library/bb510452.aspx