Your code looks a lot like OOP and inheritance. This is not how things are usually done in elixir. Based on your description I’d go for a behaviour based solution like this:

defmodule ImplBehaviour do
  @callback test(term) :: atom
  
  def call_test(impl, term) do
    impl.test(term)
  end
end

defmodule Generic do
  @behaviour ImplBehaviour

  @impl true
  fn test(_) do
    :A
  end
end

defmodule Specific do
  @behaviour ImplBehaviour

  @impl true
  fn test(3) do
    :B
  end
  
  fn test(term) do
    Generic.test(term)
  end
end

There’s no need for any hierarchy, meta programming or code sharing. Specific can call Generic.test/1 and it’s clear to anybody reading the code how/that this is happening.

In that case you could define a custom behaviour with for example a (bad named) @callback handle_special_call(message, from, state)

Then include the handle_call implementation through a macro or use MyBehaviour (which is a macro too).

And in the quoted code returned by your macro you would have something like this:

  ... previous shared handle_info clauses

  def handle_info(msg, from, state) do
    handle_special_call(msg, from, state)
  end

  def handle_special_call(_msg, _from, _state) do
    raise "Hey, you forgot to implement handle_special_call/3"
  end

  defoverridable handle_special_call: 3

Or, as others said, you just implement handle_info/3 normally, and call the parent implementation in your last clause. It’s simpler, it works well, and does not need macros.

You could get this effect with defoverridable and a little boilerplate:

defmodule Foo do
  defmacro __using__(_opts) do
    quote do
      def bar(arg) do
        IO.inspect(arg, label: "default bar")
      end

      defoverridable [bar: 1]
    end
  end
end

defmodule UsedFoo do
  use Foo

  def bar("wat") do
    IO.puts("CUSTOM")
  end

  # boilerplate
  def bar(x), do: super(x)
end

I believe the answer might be indeed “you probably should not want this”.
Instead, we usually go for one of these two more explicit approaches:

1. We fall back to code in another module by referencing it directly:

defmodule SimpleLogger do
  def log(term) do
    IO.inspect(term)
  end
end

defmodule IntLogger do
  def log(integer) when is_integer(integer) do
    IO.puts("We have an integer:")
    IO.inspect(integer)
  end
  def log(other) do
    SimpleLogger.log(other)
  end
end

2. If the code you want to fall back to is injected rather than in a separate module, we fall back using defoverridable.

defmodule ExampleServer do
  use GenServer
  
  # ... other callback implementations here

  @impl true
  def terminate(reason, state) when is_integer(state) and state > 42 do
    raise "You should have terminated me sooner!"
  end
  def terminate(reason, state) do
    super(reason, state)
  end
end

Both of these make it (reasonably) clear to the reader of the code what is going on, There is no ‘hidden’ logic.

That said, it is possible to directly inject code to the bottom of a module by using a before_compile-callback (See the module-documentation of the Module module no pun intended, I swear!), regardless of where use is used.
Can you give us a more concrete explanation of what you are trying to accomplish with this pattern?

@Qqwy, the concrete problem I was trying to solve is that I’ve got a handful of GenServer squid that are handling RPC calls via external message brokers. The nitty gritty of the networking is identical in all of them, and they share a number of handle_call()s, but there are a handful of unique ones per application. The goal was to have the client API and those specific handles be implemented in their own modules, and then add those handles on top of the shared ones implemented in the parent module with all the networking fuss.