The refactoring of how modifiers are applied by default very much LGTM! I also see you opted for ergonomic defaults (classes/interfaces/methods public, fields private), which is OK (I actually like these defaults more than the specification defaults).

I'm not sure about the utility of the public API to change the defaults though, especially with the ergonomic defaults. If I think about what I might want to do, I can imagine:

• make classes/interfaces public by default (they already are with the new defaults)
• make classes/interfaces package-private by default (I don't think they can be private or protected?)
• make methods public by default (they already are with the new defaults)
• make methods private / protected / package-private by default
• make fields private by default (they already are with the new defaults)
• make fields public / protected / package-private by default
• make classes/methods/fields final by default

That's all I can think of. I can't see anyone wanting to add any other modifier by default. If we really need to expose an API, something like this might be enough?

public interface DefaultsConfigurator {
    /**
     * Classes and interfaces are package-private by default. If not called, they are {@code public} by default.
     */
    void typesPackagePrivate();
    // alternatively, we could have: types(AccessLevel)

    /**
     * Methods on classes have the given {@code accessLevel} by default. If not called, they are {@code public} by default.
     * Methods on interfaces have a pre-determined access level that cannot be changed.
     */
    void methods(AccessLevel accessLevel);

    /**
     * Fields on classes have the given {@code accessLevel} by default. If not called, they are {@code private} by default.
     * Fields on interfaces are always {@code public static final}.
     */
    void fields(AccessLevel accessLevel);

    /**
     * Classes are {@code final} by default. If not called, they are not.
     * Interfaces are never {@code final}.
     */
    void classesFinal();

    /**
     * Methods on classes are {@code final} by default. If not called, they are not.
     * Methods on interfaces are never {@code final}.
     */
    void methodsFinal();

    /**
     * Fields on classes are {@code final} by default. If not called, they are not.
     * Fields on interfaces are always {@code public static final}.
     */
    void fieldsFinal();
}

I realize this is purpose-built and not entirely regular, and would probably have to change later with the introduction of member classes (which I'm not sure we need, frankly). On the other hand, it is a lot smaller and doesn't give rise to a huge number of combinations noone is ever going to use.

I think the general API is simple enough, and having it be internally uniform keeps things consistent and makes it easier to add new flags in the future (value types? who knows).

The problem with specific methods for categories is the same as the categories themselves: it's a little tricky to get them right, and useful categories might overlap: for example once we introduce nested classes, if I set "classes" to "package-private" I might be surprised that my nested classes didn't get affected - or I might be surprised if they did.

By spelling out each thing specifically, we'll never have to deal with these kinds of opinions. And, we keep things internally simple too, since adding creators for new kinds of things would require new modifier locations but otherwise modifiers would just work.

I don't particularly like the API, but it's small enough for me to not bother anymore :-)