Just to clarity what my concerns about the proposed API are:

I think we should not ship reflection in a state where end-user code would
be required to do something like this
whenever splicing is required (and usage shows that it is required very
often)
```
template <meta::info mo>
auto my_algo() {
    return do_something([: mo :]);
}
```
because compositions of such functions look really bad as shown in my
original message.

If we add consteval function arguments (or something) where this will be
possible:
```
consteval auto my_algo(meta::info mo) requires(reflects_type(mo)) {
    return type_identity<[: mo :]>{} // different return type for different
values of `mo`
}
```
then the whole reflection API would be much more "nice". Note that the
above would effectively be equivalent to a template function.

If we plan to deliver consteval function parameters later than reflection,
then I'd suggest not to specify the actual type of the metaobject, but
rather as:

template <typename T>
concept metaobject = __unspecified__

consteval bool some_predicate(metaobject auto mo);
consteval auto some_operation(metaobject auto mo);

and later when the consteval arguments are available just say:

template <typename T>
concept metaobject = is_same_v<T, meta::info>;

I started writing a paper with details, but it won't be ready for
tomorrow's SG7 telco.

--Matus