I've been wading through the Membership and Profile features built-in to ASP.NET. In doing so, I ran into a little nasty (yet avoidable) issue. If you override the AspNetMembershipProvider and set the ApplicationName, but don't override the AspNetProfileProvider then the Profile and Membership data will mis-match as the ApplicationId will be different. The gotcha is that it will not error out. You will just see data start being generated for two different applications in the database.
In my instance, I had set the Membership provider to ApplicationName = "foo", so the Membership data in aspnet_Users was properly linking to my ApplicationName set. Unfortunately, I did not setup the same setting for Profile data. This meant that every time I manipulated the Profile data it ended up setting up a new ApplicationName = "/" and storing all data to that application. The Profile feature is smart enough to create the user for the data, so it'll additionally duplicate the user.
I wish that there was a clearer way to identify and avoid this issue for first timers to the data. My issue was compounded by the code that I was using below to setup the default Profile data to include the UserId. (This provides the cleanest way I have found to date to use the LinqDataSource without much code by using the asp:ProfileParameter.) See code snippets below for examples.