I had been asked an interesting question around why internal class members were declared public, not internal in my PR.

internal class ProductFamily 
{
    public int Id { get; set; }
    public string FamilyName { get; set; }
}

My first thought was ‘because I always do that’, but since it was a question from a senior dev I simply attempted to change them to internal to end the debate.

internal class ProductFamily 
{
    internal int Id { get; set; }
    internal string FamilyName { get; set; }
}

This caused an issue with the program since the class was a data model for a Win Forms binding

The only solution was to leave the members as public.

This raised several questions which brought me here for answers, only to find what we previously believed, they should be allowed to be internal.
Related issue

I also remembered a different DI pattern I’ve been using lately where the implementations are internal classes, the interfaces and a static extension method to register them are in the same project as public, finally the static method is called to register them.
So the assembly using the implementations through the interface and registered services can’t see them, reducing the temptation to instantiate them.

internal class Service : IService
{
    public void DoesSomething()
    {
        ...
    }
}

public interface IService
{
    void DoesSomething();
}

public static class ServiceRegistrationExtension
{
    public static IServiceCollection RegisterServices(this IServiceCollection services)
    {
        services.AddScoped<IService, Service>();
        return services;
    }
}

My question is are these assumptions wrong, or has the paradigm shifted with modern C# versions so our understanding should change?

Setting the members to internal caused an error in the win forms binding, we were expecting it to work as normal since the understanding is the members have the same visibility as the class.