Using Standard Json Serializer - Json.Net or System.Text.Json

Looking at the current implementation, I was wondering if there were plans for supporting either Json.Net or System.Text.Json serializers. The library does not implement a standard Json serializer and only supports DataContract/DataMember attributes for renaming properties, ignores, etc.

A standard serializer would make using the library simpler in many cases, but I have two specific use cases that would really benefit:

1. Property Names

using System.Runtime.Serialization;

namespace test.app
{
    [DataContract]
    public class TestDocument<T>
    {
        [DataMember(Name = "prop_1")],
        //[JsonProperty("prop_1")]
        //[JsonPropertyName("prop_1")]
        public string Prop1 { get; set; }

        [DataMember(Name = "obj")]
        //[JsonProperty("obj")]
        //[JsonPropertyName("obj")]
        public T Object { get; set; }
    }
}

2. Json Converters - I did try implementing a custom serializer using https://github.com/OData/WebApi/issues/2271 as a reference, but we found that introducing an override there would also require overriding the URI parser for cases like selects or expands.

Ideally, the library would support implementations using one of these standard Json serializers. Either implementation would be helpful for consistency in data models and serializing more complex types like structs.
Json.Net support would be great considering the .Net5 default serializer implementation of System.Text.Json with a fallback of implementing .AddNewtonsoftJson() in cases where other libraries take heavy dependency on Json.Net. We are currently trying to piece together a .Net5 web api project that involves OData, Cosmos and Cosmos Linq queries that is proving difficult without double attributing our data models. Further, custom Json converters that aren't going to be respected are likewise hard to implement. The goal is to be able to control/be flexible with the property names persisted in documentdb outside of PascalCase or camelCase and allow for custom converters where necessary. It appears there is an option to ignore casing, but it is not quite what we need as shown in the above example casing may not be the only deviation. Any guidance would be much appreciated.