Builder/Wizard API for immutable objects

I feel like this approach isn't particularly helpful. Don't get me wrong, I think the fluent API is cool, and the use of some kind of "workflow interface" is a great idea but :

1. IMO, a Builder helps to resolve complex object creation. Your object isn't complex to create, it just takes a crazy-boring amount of time to write the code to create it. What I mean is that, for example, if an Analysis Without Ground Water was a different implementation of an Analysis, the building process would worth it because it'd hide all this implementation logic but ATM, you always manipulate an Analysis object so what's the point? It feels like an overhead and a design decision that was made because you wanted to write a cool API! Then again, maybe I'm wrong.

2. I know nothing about your program, but are all combinations of parameters possible? Aren't there more... regular set of parameters that follow some business logic? If so, you could use inheritance to create subclasses of Analysis and simply set the parameters there.

Example!

public class Analysis 
{
    public double WaterTableDepth { get; private set; }
    //All the code logic

    public Analysis(/*zillion parameters*/) 
    {
    }

}

public class AnalysisForSomeParticularScenario
{
    public AnalysisForSomeParticularScenario() : base(/*set parameters*/) {}
}

Now, if you truly have a lot of parameters, nothing stops you from changing the private setters to protected ones and set the values you want in the constructor of the subclass.

public class Analysis 
{
    public double WaterTableDepth { get; protected set; }
    //All the code logic

}

public class AnalysisForSomeParticularScenario
{
    public AnalysisForSomeParticularScenario() : base() 
    {
        //Set parameters here
    }
}

Now, maybe I'm wrong, maybe there's no logic in the creation of the object and there's nothing to regroup. Still, I have some things to say about your implementation :

var analysis2 = analysis1
        .Customize()
        .WithWaterTableDepth(200)
        .UseUWProfile()
        .Build();

That feels wrong. The building aspect of your code shouldn't be coupled to your logic class. The builder has logic itself, don't make it part of the Analysis class, it'll become huge. Doing so, you could do something like this, which feels much better :

var analysis2 = new MyAnalysisBuilder()
        .FromExisting(analysis1)
        .WithWaterTableDepth(200)
        .UseUWProfile()
        .Build();

To resume, I don't feel like a Builder is the way to go unless you're 100% sure that there's no business logic to encapsulate in your different Analysis parameters combinations. If you stick to the builder, separate it's logic from the Analysis class.

Edit

Considering there's an "unlimited" amount of parameter combinations my previous approach won't work. If you really want a Builder, we'll make one that is separated from the Analysis class. After all, in an OOP perspective, building an Analysis as nothing to do with the Analysis itself! One of the main problem I see now is that considering Analysis itself is a builder, I could do something like this :

var analysis = Analysis.Wizard.WithWaterTableDepth(20);

Now what? I didn't call Build, is my object in a good state? Is this what I want? Who knows!

Your base interface is fine, but Analysis shouldn't be an IAnalysisBuilder for the same reasons an House class isn't an HouseBuilder.

public interface IAnalysisBuilder
{
    IAnalysisBuilder WithWaterTableDepth(double value);
    IAnalysisBuilder WithoutGroundWater();

    IAnalysisBuilder UseUeqProfile();
    IAnalysisBuilder IgnoreUeqProfile();

    IAnalysisBuilder UseUWProfile();
    IAnalysisBuilder IgnoreUWProfile();

    Analysis Build();
}

You claim Intellisense will help you, but you're kind of wrong. If you use an interface, it's because you should expect people to use it. Meaning :

IAnalysisBuilder builder = Analysis.Wizard;
builder.?;

You lost your workflow's progression because IAnalysisBuilder returns IAnalysisBuilder for each method call. IMO, all your subclasses should implement IAnalysisBuilder

public interface IAnalysisWaterTableDepth : IAnalysisBuilder
{
    IAnalysisUeqProfile WithWaterTableDepth(double value);
    IAnalysisUeqProfile WithoutGroundWater();
}

And your IAnalysisBUilder should return to good type of interface according to where you are in the object's creation workflow. I know nothing about your domain so let me make an example :

interface IBuilder
{
    IBuilderWithSomeConstraint BuildWithFoo();
} 

interface IBuilderWithSomeConstraint : IBuilder
{
    IBuilderStepTwo BuildWithBar();
}

//So you can do :
IBuilder builder = new Builder();
//There Intellisense will be a tad more helpful.
builder.BuildWithFoo().BuildWithBar();

As for your builder itself, well, just take the code from the Analysis class that is used to build your object, and put it in a AnalysisBuilder class.