Newtonsoft.Json's camelCase conversion function is far more complicated than this. I don't know why. Maybe it transforms_ThisHere to_thisHere as well. As whatever this function does will be locked in for schema compatibility reasons, we should be mindful about the various prior art in this area and be sure we are comfortable with the design.

[MessagePackObject]
public class Test {
public string Name { get; set; }
public int Age { get; set; }
public string FullName { get; set; }
}

IF [MessagePackObject(keyAsPropertyName = true,keyNameCamelCase =true)]
The current Keys are: name,age,fullName

ELSE IF [MessagePackObject(keyAsPropertyName = true)]
The current Keys are: Name,Age,FullName

ELSE [MessagePackObject(keyNameCamelCase =true)]
The current Keys are: name,age,fullName

Thank you for reverting the change to the existing constructor.
I wonder if we need this constructor though. It will require folks to pass in[MessagePackObject(true, true)] to get to the camel case setting. But if you omit this constructor, this syntax is (still) available which IMO reads better:

[MessagePackObject(KeyNameCamelCase = true)]

Or, if you take my suggestion about enums, a new constructor would work that would be even simpler:

[MessagePackObject(KeyPolicy.CamelCasePropertyNames)]

fixed

Thanks. Not quite what I was thinking of, but I pushed a change to show my intent.

This would make a more informative sample if the property names were multiple words long, so that those not familiar with camel case can readily see that only the first letter is lowercase and the rest are left alone.

Nope, can't do that. Removing a public property is a breaking change. That's why I added theObsolete attribute instead of removing it.

What wecould do though, is replace it with something that doesn't need to be set in the constructor, like this:

[Obsolete($"Use{nameof(KeyPolicy)} instead.")]publicboolKeyAsPropertyName=>this.KeyPolicyisKeyPolicy.ImplicitPropertyNames orKeyPolicy.ImplicitCamelCasePropertyNames;

I think KeyAsPeopleName can be cleaned up before merging the main code.
Using Obsolvete will make the code more chaotic, and concise code will make it clearer to understand.

You seem to think this is up for debate. It is not. Breaking changes are unacceptable in a stable library such as this one. The propertymust remain. The only question is whether to add the[Obsolete] attribute to it. In this case I believe it should, because it is both redundant with the new property and somewhat hazardous for anyone depending on it since it no longer is guaranteed to mean what it used to as a 3rd mode has been added.
And considering almost no one is everreading this property outside of this library, adding Obsolete to it is unlikely to upset anyone.

Thanks for the tests. They'll be more useful if the property names had multiple uppercase letters in them so that we can verify that only the first letter is changed.