Если класс internal имеет ли смыслс помечать его как sealed или компилер по умолчанию считает internal классы sealed?
Программирую за еду.

internal - вроде как, может использоваться только внутри сборки,
а sealed - не может иметь наследников.
Почему компилер должет думать что internal это sealed

sealed -- это гарантия того, что виртуальный метод можно смело инлайнить (т.к. его не перегрузить). По идее у интернал тоже не должно быть наследников (хотя его можно достать из сборки через жопу, но это порблема того, кто его достал) => к нему можно применять ту же оптимизацию, что и к sealed. Вопрос в том, стоит ли мне перед каждым внутренним классом писать sealed или я просто зря буду расходовать ресурс клавиатуры?
Программирую за еду.

Почему вы думаете что у интернал не должно быть наследников.
Если у вас в сборке есть класс fooProvider, для работы с foo, и есть класс foo2, у него провайдер foo2Provider - наследник fooProvider.
И вам необходимо что бы провайдеры были доступны только для этих двух классов, а все кто использую сборку о них не знали, вы помечаете их как internal

Всё фигня кроме пчёл.
Инлайн оптимизация работает так:

Foo2 bar = foo2Provider.Baz()
bar.Quux();

если известно, что у Foo2 не может быть наследников, Quux() можно инлайнить, даже если он виртуальный. Если написать:

Foo bar = fooProvider.Baz()
bar.Quux();

даже если вместо Foo возвращается sealed Foo2 никакой оптимизации не будет.
Но тут V.Petrovski правильно всем напомнил про InternalsVisible, значит у internal может быть вполне законный наследник в сборке, про которую компилятор ничего не знает, значит для финальных классов сеалед нужно писать вне зависимости от того интернал он или нет.
Программирую за еду.

Может просто посмоттреть IL в том и другом случиях?

Безполезнячок.
IL полностью соответсвует исходнику. Всякие оптимизации начинаются при компиляции самого IL. Да и что там смотреть? и так все понятно...
Программирую за еду.

Дык зачем так себя мучить? и так вроде разобрались...
Программирую за еду.