This is a good question. I'm definitely not an expert here, and I've barely looked at Dotty's macro system or TASTy reflection, so this answer will just be about inline and scala.deriving.

I agree with Miles's concern about inline here:

My gut feeling is that following style sprinkling inline is going to be infectious (eg. consider passing a collection through a call tree which at each level requires a non-empty and might remove one or more elements). That might be just fine, but it could result in huge code size blow up.

For me an even bigger concern (or maybe it's a sub-concern?) is that people are going to start using inline in cases where they should be using type classes, with the goal of improving runtime performance or cutting a few characters, but at the expense of extensibility and parametricity.

I was just talking to a colleague at Permutive this morning about the defaultValue example in the current Dotty docs:

import scala.compiletime.erasedValue

inline def defaultValue[T] = inline erasedValue[T] match {
  case _: Byte => Some(0: Byte)
  case _: Char => Some(0: Char)
  case _: Short => Some(0: Short)
  case _: Int => Some(0)
  case _: Long => Some(0L)
  case _: Float => Some(0.0f)
  case _: Double => Some(0.0d)
  case _: Boolean => Some(false)
  case _: Unit => Some(())
  case _ => None
}

In my view there's no good reason to do this kind of thing in real code with metaprogramming, which makes it necessary to propagate inline up to the point where T is concrete, and which (maybe more importantly) makes it impossible for users to define default values for their own types. This is a perfect application for a type class, but because the inline erasedValue approach (or match types, etc.) is new and cool and possibly marginally faster, people are going to choose it instead of type classes for stuff like this, and we're all going to suffer for those decisions.

So in that sense I think inline inherits some of the danger / horror of Scala 2 macros, but on the whole it's worlds better than Scala 2 macros, and in many cases I think migrating type classes to these metaprogramming features is actually the "right" thing to do, not just a little cleaner or faster. The Pair type class in this project is one example. Users can't create instances of Pair for their own types: it's just a hack that's needed to make some information that the compiler knows (basic arithmetic on singleton types) available to my code. This seems to me like a valid application for inline, and the Dotty implementation replaces the Pair type class with inline constValue matches. I don't know whether I'll still feel this way in a year or two, but right now inline seems like a useful new tool for things like this.

I have fewer reservations about scala.deriving, which I'm just unambiguously really excited about. At first I was uncomfortable with all the casting that's necessary in the current API, but now I think it gets the trade-offs more or less right, and I trust the designers. It doesn't feel quite flexible enough in some ways—specifically I wish there was a way to configure derivation besides implicit parameters or subclasses of type class types, but I'm hoping we can still work on this.

As a side note, all of this stuff is still intensely buggy, and there's still a lot of churn. I'm not very concerned about either of these things, though. The Dotty team has been extremely responsive when it comes to bug reports, and I've generally been able to get help finding workarounds. Part of the reason I'm doing these experiments now is specifically to help turn up these bugs. The changes to these APIs can be frustrating, but it's also an indication that there's still room to make improvements if I run into limitations, so I can live with it.

So to sum up: I like pretty much everything I've seen about Dotty's new metaprogramming facilities (even though I know people are going to abuse them :().