When we were architecting this site, we wanted to make sure that it was using Forms Based Authentication (FBA) and the SQL Membership Provider to ensure that we had an easy way to allow members to register on the site without having to go through AD or the local domain accounts of the server.
In other words, we were lazy. We didn't wan ot have to try to maintain that membership and add people and keep track of the membership. It would be much simpler to allow people to just sign up directly on the site and get all of the features registered users get (post content, subscribe to lists, etc).
This was a bit of a struggle to do (maybe I or one of the other guys will post what we went through to get it up and running) but we finally got it working. We all patted ourselves on the back. Good job team!
But then we tried to edit some content (for branding) in SharePoint Designer (SPD). Oops. It didn't work. In fact, the first time I tried updating the Master Page for the site, I completely hosed the front page. Somehow, it took all of the rendered HTML and saved it back to the file. There was no longer any .NET or SharePoint controls. There was no longer a Master Page. It was just straight up HTML. Oops.
So, to make this work, I went into Central Administration for the site and extended the web application for the site collection. This defaulted to using Active Directory (or local server domain accounts) again, which is what we wanted. It then allowed me to access the same content (content database) via a separate port number. I have the same site, just different authentication methodology. As soon as I did that, I could modify the site in SPD again. I opened up the port to the other guys on the team and now they can use SPD for this site as well.
There is one consideration, though, that I didn't think of. When you extend the web application and, thus, create a new entry point to the site through a different port, you create a copy of the static files in IIS on your server. So, say, your original files were located here:
C:\INETPUB\WWWROOT\WSS\VirtualDirectories\80
You would now have the same static files located somewhere else, like this (where "1234" was your new port):
C:\INETPUB\WWWROOT\WSS\VirtualDirectories\1234
For the most part, this is fine. However, I had tweaked the web.config file to add some safe controls for the port 80 site and guess what? They weren't safe in teh 1234 port. This makes total sense considering web.config is one of the static files (not stored in the SP databases) and, as such, will have copies in both the 80 and 1234 directories. But I hadn't thought of it.
I still like this approach to handling this issues and, for the most part, this issue probably won't come up that often. But it is still something to think about if you ever decide to take SharePoint to FBA.