Unbalance external workflow configuration?

Is your feature request related to a problem? Please describe.
Workflow configuration can be achieved in two different ways. The first one, descrived on docs is through the Workflow implementation constructor, like the following (snipped code taken from tutorial):

public class MoneyTransferWorkflowImpl implements MoneyTransferWorkflow {
    private static final String WITHDRAW = "Withdraw";
    // RetryOptions specify how to automatically handle retries when Activities fail.
    private final RetryOptions retryoptions = RetryOptions.newBuilder()
            .setInitialInterval(Duration.ofSeconds(1))
            .setMaximumInterval(Duration.ofSeconds(100))
            .setBackoffCoefficient(2)
            .setMaximumAttempts(500)
            .build();
    private final ActivityOptions defaultActivityOptions = ActivityOptions.newBuilder()
            // Timeout options specify when to automatically timeout Activities if the process is taking too long.
            .setStartToCloseTimeout(Duration.ofSeconds(5))
            // Optionally provide customized RetryOptions.
            // Temporal retries failures by default, this is simply an example.
            .setRetryOptions(retryoptions)
            .build();

By doing this, configuration seems a little hardcoded. But I can have 3 levels of ActivityOptions:

1. A default one that applies to all non-configured activities, by giving defaultActivityOptions to all activities during creation time except those that requires a particular configuration, method to be used Workflow.newActivityStub(Class<T> activityInterface, ActivityOptions options)

2. A particular Option to all methods on a particular Activity, by creating a particular ActivityOptions instead of default and passing it as argument to Workflow.newActivityStub(Class<T> activityInterface, ActivityOptions options) when creating the activity instance.

3. A method base option map, further configuration might be achieved by using Workflow.newActivityStub(Class<T> activityInterface, ActivityOptions options, Map<String, ActivityOptions> activityMethodOptions), where each method of the activity can have its own ActivityOptions. (This approach is a little tricky since it doesn't support polymorphism)

On the other way, to avoid hardcoding configuration, We can use Worker.registerWorkflowImplementationTypes(WorkflowImplementationOptions options, Class<?>... workflowImplementationClasses), by doing so, we need to pass WorkflowImplementationOptions containing defaultActivityOptions that matches point 1 and also activityOptions that matches point 3 of the other approach. But this strategy misses the second point of the above approach, leaving only a default activity option for the whole workflow activities and expose limitation over method polymorphism inside the same activity class (same problem as the method above) and adds a new unique limitation that requires not activities sharing method names.

Describe the solution you'd like
Leaving the local method polymorphism method limitation aside, it would be awesome to balance this two configuration strategies to be able to achieve the same without sacrificing functionality.

Describe alternatives you've considered
Not much, I have been struggling with this for a while now.

Additional context
None so far.

Start by comparing Workflow.newActivityStub(Class, ActivityOptions), its method-options overload, and Worker.registerWorkflowImplementationTypes(WorkflowImplementationOptions, Class<?>...). Define how workflow-level, activity-level, and method-level options should achieve equivalent behavior, including method-name collisions and polymorphism; done means the supported configuration paths are balanced and their limitations are documented or tested.