@304NotModified @NKnusperer Opinion on #139 (comment) appreciated

Nice PRs! Will try to review this weekend!

@304NotModified @NKnusperer
Would be great if you found few minutes for the open for discussion part or review in general ;-)

Open for discussion:

• Should Exceptions use CultureInfo.InvariantCulture, CultureInfo.CurrentCulture or Options.Culture. The latter is complex with no value IMHO.

CultureInfo.InvariantCultureorCultureInfo.CurrentCulture` looks good to me.

• Should utility classes (like mentioned as breaking changes) rather be internal than public?

Yes those should be internal

• Is the Limitation above acceptable? Of course must become part of the docs (know the consequences leaving defaults or alike)

Sounds logical to me :)

@axunonb I'am in vacation till the end of the week. I will try to catch up next week.

@NKnusperer have a good holiday!

@NKnusperer Hi, hope you some beautiful days off ;-)
Did have a look at #139 (comment) already?
Especially: public classes / methods which had better become internal. A major release were a good opportunity for that, but we have to be careful about the right approach.

Should Exceptions use CultureInfo.InvariantCulture, CultureInfo.CurrentCulture or Options.Culture. The latter is complex with no value IMHO.

With exceptions you're talking about the message?
If so, values that are internally treated as culture-invariant should use CultureInfo.InvariantCulture and vice versa.

Should utility classes (like mentioned as breaking changes) rather be internal than public?

Yes.

Is the Limitation above acceptable? Of course must become part of the docs (know the consequences leaving defaults or alike)

Absolutely.