Does this behave as expected?

declare const bool: boolean
expectAssignable(server.get<{
  Reply: {
    200: "hello_200"
    400: "hello_400"
  }
}>(
  '/',
  async (_, res) => {
    if (bool) {
      res.status(200)
      return "hello_200"
    }

    res.status(400)

    return "hello_400"
    
  }
))

expectError(
  server.get<{
    Reply: {
      200: "hello_200"
      400: "hello_400"
    }
  }>(
    '/',
    async (_, res) => {
      if (bool) {
        res.status(200)
        // Doesn't match declared 200 
        return "hello_400"
      }

      res.status(400)
      // Doesn't match declared 400
      return "hello_200"
    }
  )
)

I'm not sure if this is possible. This PR only enables you to return 'hello_200' without type assertions return 'hello_200' as unknown as { 200: 'hello_200', 400: 'hello_400' }. The behavior aligns with that of other methods of defining return types, e.g. via typebox.

Ok, so I don't understand why to allow this? You have use cases when you need to mix chained .status(statusCode).send(body) method with direct return?

Ok, so I don't understand why to allow this?

Well, defining Reply with status codes is valid, then returning Reply[code] from a handler should be valid as well. Currently, if you define Reply types with json schema/typebox, you can return Reply[code] without issues. However, if you define types with RouteGeneric, you just can't return Reply[code] without semantically wrong type assertions. That's a bug.

You have use cases when you need to mix chained .status(statusCode).send(body) method with direct return?

Yes, I mix .status(code).send with return. People do that all the time. It's natural to return a value from a function, and throw or return reply.status().send() when you don't. It's just people often use fastify typescript with a type provider like typebox/zod and they don't have this problem.

I instead use some sort of a plugin/compiler to generate json schemas from the generic types and register them with fastify.