I have an idea.

The original issue was because the line processor list being populated on ModuleConfiguration is not the same list on ScriptServicesBuilder.  Both classes inherit from ServiceOverrides and the only reason the overrides dictionary is shared is because they both pass the dictionary through to the ServiceOverrides constructor.  The line processors list wasn't being passed through in this way, so adding a processor in a custom module wasn't being recognized.

What I was thinking is that instead of ScriptServicesBuilder and ModuleConfiguration inheriting from ServiceOverrides, they can each have a public Overrides property that would be the ServiceOverrides instance and not the dictionary.  Then we could make the dictionary on ServiceOverrides private and only manipulate it through the methods on the class.  When creating the module config, we'd just pass in the ServiceOverrides object instead of the dictionary.  Same for RunTimeServices.

That's a little bit bigger of a change, and ServiceOverrides may need some methods added to expose the dictionary values.

Another thing to consider going that route would be to keep ModuleConfiguration implementing IServiceOverrides so that it can expose the same methods but just call the ServiceOverrides implementation internally.  This would keep the change from affecting existing modules.  They could still use moduleConfig.ScriptEngine or any of those methods - it would just pass through to ServiceOverrides.  Then the Overrides property may not need to be public.

There are probably some holes in that idea, but it seems like a potential solution.  It wouldn't change the how the list processors are stored on ServiceOverrides in dev now, but it would change other class implementations, which could be a concern.  Is there every a time where would need multiple instances of a set of overrides?  Could ServiceOverrides potentially become a singleton instead of being passed between the different classes that use it?

If you guys decide that a different implementation is needed (either replacing this PR or as a follow up), I've got some time this weekend to work on it.