That doesn't look like an alternative to the visitor pattern, that basically IS the visitor pattern. If you replaced the magic of Fix T + fold with an equivalent to accept(), you would end up having written exactly the Visitor pattern just with pattern matching instead of virtual dispatch and sum types instead of subtypes.

Here is the exact same example in fully working C# (you can do the same in Java or C++, C# is just a little more terse; you could do it in Go as well, but it would be much uglier because you don't have generics).

// ------ BEGIN : In some external library
interface ExpressionOpen { T accept<T>(Evaluator<T> eval) => throw new NotImplementedException("Unsupported combination"); }
record Literal(int n) : ExpressionOpen{
public T accept<T>(Evaluator<T> eval) => eval.visitLiteral(this);
}
record Addition(ExpressionOpen x, ExpressionOpen y) : ExpressionOpen {
public T accept<T>(Evaluator<T> eval) => eval.visitAddition(this);
}

interface Evaluator<T> {
T visitLiteral(Literal l);
T visitAddition(Addition a);
}
class StringEvaluator : Evaluator<string> {
public virtual string visitLiteral(Literal l) => l.n.ToString();
public string visitAddition(Addition a) => a.x.accept(this) + "+" + a.y.accept(this);
}
class ExecutionEvaluator : Evaluator<int> {
public int visitLiteral(Literal l) => l.n;
public int visitAddition(Addition a) => a.x.accept(this) + a.y.accept(this);
}
// ------ END : No longer in some external library

// ------ BEGIN : My own code

//note: no need for ComplexEvaluator here
class HexadecimalEvaluator : StringEvaluator {
public override string visitLiteral(Literal x) => x.n.ToString("x");

// thanks to inheritance, the existing expressions can already accept this
// so no need for an equivalent for extendedEvaluator;
// we're also inheriting visit(Addition) but that is not fundamental
}

interface ComplexExpressionOpen : ExpressionOpen { T accept<T>(ComplexEvaluator<T> eval) => throw new NotImplementedException("Unsupported combination"); }
record Multiplication(ExpressionOpen x, ExpressionOpen y) : ComplexExpressionOpen {
public T accept<T> (ComplexEvaluator<T> eval) => eval.visitMultiplication(this);
}

//but we do need ComplexEvaluator to go with ComplexExpression
interface ComplexEvaluator<T> : Evaluator<T> { T visitMultiplication(Multiplication x); }

class StringEvaluatorExtended : StringEvaluator, ComplexEvaluator<string> {
public string visitMultiplication(Multiplication m) => m.x.accept(this) + " * " + m.y.accept(this);
}

class ExecutionEvaluatorExtended : ExecutionEvaluator, ComplexEvaluator<int> {
public int visitMultiplication(Multiplication m) => m.x.accept(this) * m.y.accept(this);
}

class HexadecimalEvaluatorExtended: HexadecimalEvaluator, ComplexEvaluator<string> {
public string visitMultiplication(Multiplication m) => m.x.accept(this) + " * " + m.y.accept(this);
}
class HexadecimalEvaluatorExtended: HexadecimalEvaluator, ComplexEvaluator<string> {
public string visit(Multiplication m) => m.x.accept(this) + " * " + m.y.accept(this);
//if C# supported multiple inheritance, we wouldn't have needed to repeat ourselves here:
//we could have just inherited both HexadecimalEvaluator and StringEvaluatorExtended
}

//we don't need any kind of boilerplate similar to evaluateExtendedExpression.

// ------ END : Finished with my own code

You'll notice that (disregarding how verbose the language still is) we have actually written significantly less code - we haven't repeated a single line of code.

Also note that your example only works in languages which have discriminated unions, pattern matching, compiler macros, and support for recursive types. Without any of these, it becomes even more verbose and harder to extend than the actual visitor pattern.