Consider: Would ɵisInternal improve typing without expanding our public API contract?

@internal actually effectively removes the prop from the public API. (it's not present in the generated d.ts.

Consider: It seems easy to forget the ngDevMode bits here (or misuse it like isInternal: ngDevMode ? true : undefined), especially if we're doing this manually at each call site. We also won't have extensive tests that this is a zero-cost addition in production.

IIRC, the debug name transform wraps an explicit name in an ngDevMode conditional (might be worth double checking that). What if we boxed both debugName and isInternal into a shared debugInfo object and tree shake that value once rather than having to do each one individually?

// Definition

interface DebugInfo {
  name?: string;
  isInternal?: boolean;
}

declare function signal<T>(initial: T, opts?: {debugInfo?: DebugInfo}): WritableSignal<T>;

// Dev writes:

const foo = signal(0, {
  debugInfo: {isInternal: true},
});

// Transformed to (using our existing infra, just tweaked for `debugInfo` instead of `debugName`):

const foo = signal(0, {
  ...(ngDevMode ? {
    debugInfo: {
      name: 'foo',
      isInternal: true,
    },
  } : {})
});

This way we don't need to think about tree shaking at each call site, we just annotate which signals are internal.

I know we're just experimenting here for now, so I'm fine to come back to this later. I'm mainly calling out that there might be value in a DebugInfo abstraction which allows us to introduce new debug state in the future without having to reinvent the tree shaking solution we need for production.