I see no sense to simply move JNoSQL from a separate project under the "Technology" umbrella into the "shark pool" of MicroProfile. As seen with Config and a few other cases (e.g. the REST proxy) those involved as project or spec leads have a hard time keeping up all their efforts and the Config JSR is behind schedule based on JCP.next expectations and guidelines. Because there are other duties and responsibilities they got in MicroProfile "features". There are no clear sub-projects therefore the whole versioning is messy and with a so far active version cycle JNoSQL would even make that worse.
Plus MicroProfile aside from a few dedicated glue projects for other external systems and ecosystems looks very much like a collection of popular Microservice patterns from: https://microservices.io/index.html
A kind of "GoF equivalent" in the Microservice space.
There are a couple of Data related patterns like https://microservices.io/patterns/data/database-per-service.html or "Saga". Which could find support in another MicroProfile feature or multiple, but neither of these patterns mandate that you have to use relational databases, plain file stores or NoSQL databases. That would be counterproductive. Which is why JNoSQL could be used to support some of these patterns, but I see no reason why JNoSQL should move to MicroProfile rather than EE4J, that is where it should be aim for when the time comes.
Werner