GeezerVison

I think this may have more global utility. Could this be public?

Should this really be made public without also making it static? If so, then I will go ahead and make the change. If not, then if this should be changed to be both public and static, then I would ask to postpone this change to a subsequent pull request in which additional related refactorings can be made. This is because--as far as I understand it--rendering a Settings object constructible via a static Parse...(Hashtable) method (i.e. a factory method) should be coupled with deprecating its constructibility from a yet-to-be-parsed Hashtable via a public constructor, and thus also refactoring any extant client logic (e.g. in the "Engine/Settings/InvokeScriptAnalyzerCommands.cs" file).

it looks like the first element to cause an error will move on to the next element, so if there are multiple issues, they won't be caught until the user fixes the previous break. Is there a way to keep going on in some of these cases and find all the issues in the setting?

James Truher (@JamesWTruher) Which case(s) in particular are you referring to? To the best of my knowledge, I have sequenced the checks here such that there is no case where a preceding failed check (that currently results in a continue) would either semantically or logically allow a subsequent check (on the same element) to be performed. The only exception I can see is perhaps the uniqueness constraint, which I will update momentarily to not continue on failure.

c7ff89b updates the uniqueness check to not continue to the next element on failure, but rather proceed to check the current element's value as well.

Given that this is the only change in this file, I'm assuming this isn't used and can be taken out?

I think a method with StringOrStrings in it is a strong indicator that this method should be broken into an overload for string and overload for IReadOnlyList<string> and an entry point overload for object that uses a pattern match switch.

Also Parse doesn't really indicate well what's going on, since we're not trying to read this from a string. I think this a Convert or similar.

So I'd imagine this being written like this:

private List<string> GetSettingFromInput(object value, string settingName, ref List<Exception> exceptions)
{
    switch (value)
    {
        case null:
            exceptions.Add(...);
            return null;

        case string str:
            return GetSettingFromInput(str, settingName, ref exceptions);

        case IEnumerable enumerable:
            return GetSettingFromInput(enumerable, settingName, ref exceptions);

        default:
            exceptions.Add(...);
            return null;
    }
}

private List<string> GetSettingFromInput(string str, string settingName, ref List<Exception> exception)
{
        return GetSettingFromInput(new [] { str }, settingName, ref exception);
}

private List<string> GetSettingFromInput(IEnumerable enumerable, string settingName, ref List<Exception> exceptions)
{
    var settings = new List<string>();
    foreach (object element in enumerable)
    {
        if (element == null)
        {
            exceptions.Add(...);
            continue;
        }

        if (!(element is string strElement))
        {
            exceptions.Add(...);
            continue;
        }

        settings.Add(strElement);
    }
    return settings;
}

Note that here you don't need to use ref to pass the List<Exception>, but it helps to indicate that you intend it to be both passed in and mutated. The other possibility would be to return a tuple to lower the onus on the caller.

I don't see you use the settingName variable anywhere other than errors, but presumably that's just a question of error tracing.

If a change like this is made, I think it may as well be a change to _includeRules instead. That's admittedly more of a style opinion, but it's consistent with other PowerShell code and a less verbose way of designating a private field.

== is more appropriate here since it really does test referential equality. The only language I know where is is conventional for a nullity check is Python (because it doesn't really have a null, but a singleton object None that references default to).