Why not simply do this in a separate Go package, e.g. github.com/my-org/queue-proxy and then have main.go:

package main

import "github.com/IBM/go-security-plugs/qpsecurity"
import "knative.dev/serving/pkg/cmd/queue"

import _ "github.com/IBM/go-security-plugs/plugs/testgate"
import _ "github.com/IBM/workload-security-guard/wsgate"

func main() {
  qpExtension := qpsecurity.ConfigFromAnnotationFile("/podinfo/annotations", "rtplugs")
  defer qpExtension.Shutdown()
  queue.mainWithPlugs(qpExtension)
}

Let's break this down to a couple of items:

1. queue.mainWithPlugs(qpExtension) - moving the current code in main.go to a separate pkg such as "knative.dev/serving/pkg/cmd/queue" (or a pkg under it) seems like a good option
   (if everyone is on board with this move) and does simplify the extendibility option as shown.

2. As for qpExtension := qpsecurity.ConfigFromAnnotationFile("/podinfo/annotations", "rtplugs"):
   qpsecurity is a QP specific glue pakage, so we need not have this call, it can read from "/podinfo/annotations" (if that is an agreed QP core path for the annotations) during e.Init(). It can reside in the sandbox, moving forward. It can be renamed qpextender.

3. defer qpExtension.Shutdown() - as indicated other comment - is a less attractive option due to flush().

Two questions:

1. Do we need this interface at all? Between package-level init static functions and the Transport interface (which could take a ctx), it seems like you can cover "anytime" initialization and "when loaded" initialization. Similarly, Shutdown could just be deferred outside MainWithPlugs unless you expect the Shutdown to need to interact with objects that are cleaned up in a defer on MainWithPlugs (I don't see any such thing).

2. Do you need to pass both a ctx and a logger, since you can get your logger from the ctx? If so, the golang convention is that the context.Context should go first.

1. To Interface or not to Interface, that is the question:
   If we interface:
   (a) we open up for growing extendibility as we move forward, without cluttering the core code.
   (b) we are not bound to limit ourselves to a single call to the extension (and maneuvering around it)
   (c) in the future, if we allow several extension points, we can allow an extension to use more than one
   (d) this requires extensions to align with the interface (once it changes to include additional calls)

   If we do seek to squeeze into a single extendiability point, we can have:
   e.transport = Transport(ctx, logger, transport)
   This will work for removing e.Init(ctx, logger), but is this the right way forward?

   It is a reasonable assumption that other extendibility will be needed as we move forward, and all will need Init(). For example, we may have an extension that only requires Init() but not Transport() (Do we really want it to use Transport() as a fake Init(), making the code unreadable?). Also, we may have an extension (security, tracing, metrics, container freeze, etc. ) requiring additional hooks beyond Transport(). Instead of creating a MainWithThisHook() and MainWIthThatHook() for each one, we can make it generic and all will use the same interface (and use what they need from that interface, skipping the rest).

   As for the e.Shutdown(), if we avoid the interface, we can solve it in main().
   But if we keep the interface, having it seems like the right way to go.
   (As noted in a different comment, flush complexity is removed by having Shutdown())

2. Do we need to pass a logger?

(2a) Right, the order needs to be Init(ctx, logger) - A fix was sent

(2b) We need: One logger to rule them all.
Extensions need to use the logger controlled and being setup by core.

logger, _ := pkglogging.NewLogger(env.ServingLoggingConfig, env.ServingLoggingLevel)
defer flush(logger)

logger = logger.Named("queueproxy").With(
	zap.String(logkey.Key, types.NamespacedName{
		Namespace: env.ServingNamespace,
		Name:      env.ServingRevision,
	}.String()),
	zap.String(logkey.Pod, env.ServingPod)) 

3. Note that this commit does not address extension configuration (not even which extension is activated and which is not during the current execution of QP). For example, an extension may require knowing information such as: ServingNamespace , ServingRevision , ServingPodIP , ServingPod, ServingService etc. Apart from per-extension-specific configs such as on/off the flag and possibly more. Apart from the question about how this information is being configured and propagated to the container, we should ask if we expect each extension to read/parse the config parameters separately or do we transfer at least a set of configs already parsed by the core to all extensions during Init() - for example e.Init(ctx, logger, extconfigs) where extconfigs will include ServingNamespace et al.

The only benefit I see of having Shutdown be part of the interface (rather than being part of the function outside MainWithPlugins) is that it may take advantage of the call to flush() on line 131.

The cost is that every implementation of queue.QPExtension must implement Shutdown. The alternative is to make Flush public, and ask callers which care to run flush again.

A third option is to have MainWithPlugs() return a func() for final cleanup which would return func() {flush(logger)}. This would have the advantage that it also worked with other post-MainWithPlugs code, with the disadvantage that you'd want to call MainWithPlugs as defer MainWithPlugs(myhandlers...)() or the like.

yep, since defer flush(logger) is called first, and defer ext.Shutdown() after,
flush() will be called after Shutdown()

This seems like a clean way to go.