Indeed this functionality is currently not quite supported by SwinjectStoryboard - I have answered more in depth in the SO issue.

First of all thanks for the quick response.
I've read your answer on SO, and after that I've checked the open PR and had an idea of an alternative approach I would love hearing your thoughts on it:

Currently when calling instantiateViewController(withIdentifier: "identifier") you will instantiate the relevant viewController that has storybaordID equals to the given identifier from the storyboard.
You than inject it with the right dependancy, and if there are few resolving available you distinguish using the name which is, as far as I understand, being compared to the swinjectRegistrationName runtime attribute.

What if you would specify in the storyboard the available swinjectRegistrationNames (in a form of array) and extend instantiateViewController(withIdentifier: "identifier") to have another String variable (something like: instantiateViewController(withIdentifier: "identifier", name: "aName").
This way, you could run over the entire list of available names (taken from swinjectRegistrationNames) and if one matches with the requested name just resolve and inject it...

Thanks for the idea 👍

If we wanted to add the name parameter to the instantiateViewController(withIdentifier:) we wouldn't even need to use array of names in the storyboard - swinjectRegistrationName parameter is used to "select" the correct storyboardInitCompleted definition (simplifying here a bit 😉). We could simply use the method parameter instead.

However, I'm not quite sure whether this is the right path to take: Initial idea behind the SwinjectStoryboard was to allow users relying on "hidden" instantiation of view controllers from storyboard (e.g. segues, child containers, ..) to inject dependencies. Once you need to use names in instantiation you cannot rely on these mechanisms anyway, so you might as well instantiate the view controllers manually:

container.register(MyViewController.self, name: "name") {
    let vc = SwinjectStoryboard.create(name: "MyStoryboard", bundle: nil).instantiateViewController(withIdentifier: "identifier")
    vc.viewModel = $0.resolve(MyViewModel.self)!
    return viewModel
}

let vc = SwinjectStoryboard.defaultContainer.resolve(MyViewController.self, name: "name")

My fear is that once we start extending instantiateViewController method we might end up reimplementing more and more of a "native" Swinject API. Which requires a lot of work and IMHO doesn't add much value compared to the usage described above.

BTW: this argument works for adding resolution arguments (SwinjectStoryboard #62), which is taking the framework in the same direction.

Well, according to your answer and a brief look on the implementation in SwinjectStoryboard.swift, it looks like swinjectRegistrationName is behaving as the name parameter which "select" the right
storyboardInitCompleted definition.

Will adding a default value nil for this potential name: String? extra param and choosing it over the swinjectRegistrationName param (or, alternatively, to remove the need of this attribute completely) still make you feel it might end up reimplementing more and more of a "native" Swinject API?

Because as I see it - from the moment you've instantiated the view controller from the storyboard, all you do is injecting the dependancy and return the injected viewController.
Maybe I'm missing something, but will something like that:

 public override func instantiateViewController(withIdentifier identifier: String) -> UIViewController {
        SwinjectStoryboard.pushInstantiatingStoryboard(self)
        let viewController = super.instantiateViewController(withIdentifier: identifier)
        SwinjectStoryboard.popInstantiatingStoryboard()

        injectDependency(to: viewController, nil)

        return viewController
    }


  private func injectDependency(to viewController: UIViewController, name: String?) {
        guard !viewController.wasInjected else { return }
        defer { viewController.wasInjected = true }

        // This could be omitted, or alternatively be used only if name is nil?
        let registrationName = name ?? viewController.swinjectRegistrationName

        // Xcode 7.1 workaround for Issue #10. This workaround is not necessary with Xcode 7.
        // If a future update of Xcode fixes the problem, replace the resolution with the following code and fix storyboardInitCompleted too.
        // https://github.com/Swinject/Swinject/issues/10
        if let container = container.value as? _Resolver {
            let option = SwinjectStoryboardOption(controllerType: type(of: viewController))
            typealias FactoryType = ((Resolver, Container.Controller)) -> Any
            let _ = container._resolve(name: registrationName, option: option) { (factory: FactoryType) in factory((self.container.value, viewController)) as Any } as Container.Controller?
        } else {
            fatalError("A type conforming Resolver protocol must conform _Resolver protocol too.")
        }

        for child in viewController.childViewControllers {
            injectDependency(to: child, name)
        }
    }

public func instantiateViewController(withIdentifier identifier: String, name: String? = nil) -> UIViewController {
        SwinjectStoryboard.pushInstantiatingStoryboard(self)
        let viewController = super.instantiateViewController(withIdentifier: identifier)
        SwinjectStoryboard.popInstantiatingStoryboard()

        injectDependency(to: viewController, name: name)

        return viewController
    }

could cause any issues and will move the library to the direction you mentioned is wrong?

This issue was moved to Swinject/SwinjectStoryboard#96