The scm-api and branch-api plugins allow you to clearly organize a project by branches. Currently the Literate plugin and some others make use of them. It would be desirable for many flows to use this plugin so that builds from each branch of a repository are tracked independently.
Cannot make flows enforce use of this in all cases (like Literate does), because general flows could check out from multiple repositories, do custom merge operations, and so on—things that cannot be statically represented as a set of branch subprojects. But for the common case where the flow is associated with a single repository, and it is going to do a standard CI clone/update step on a branch triggered by changes (like an AbstractProject with SCM enforces), it would be desirable to present a standard UI.
The project configuration could specify the SCM sources and a label to check them out on, and the flow script would have to be run inside an implicit node block after checking out the branch. As a more flexible alternative, the current branch name could just be passed into the flow as a variable, which would then be responsible for doing the checkout itself. This is tricky because SCMSource.build(SCMHead, SCMRevision) is designed to return a live SCM, not metadata like branch names. Potentially the SCM itself (or its DescribableHelper.uninstantiate representation) could be passed as the variable, which you would pass with or without modification to the checkout step.
As far as the existing APIs are concerned, a workflow could easily be an SCMSourceOwner. The main blocking issue is that MultiBranchProject and the like assume AbstractProject/AbstractBuild and so need to be refactored to allow Job/Run (perhaps with some further restrictions).
SCMSource does not seem to support workspace-based polling, nor differentiating significant from insignificant changes (consider MercurialSCM.modules for example). However the literate plugin does not seem to use it directly for polling anyway; rather it creates the SCM and then uses that for polling.