Bearing in mind what you said backporting packages, if we want this in our PPA, I’m not sure whether I should:
My only real caution was including a dependency package in the PPA that was going to break some core ubuntu library. Backporting for the latest gnuradio out of tree packages is specifically the right kind of thing for this PPA. And if the build requires a external package thats in a separate PPA like GLFW3 PPA, then there definitely wont be a problem.
Now someone who wants to use myriadrf gnuradio gr-fosphor has to also add the GLFW3 PPA, and that could cause some breaking package replacement… that’s unfortunate, but its more of an edge case. And what else can you do? In general, we are talking about development versions of these new packages that causes incompatible situations, so it really is more of an edge case. If someone is developing something with this GLFW3 library, and wants to use the native ubuntu dev version, they might have to just not use this particular PPA… 
So if all of the dependencies for the gr-fosphor can be met either by the gnuradio PPA or by adding dependencies to the PPA, then “backportpackage” may be the easiest way to handle this. Its a single command which will download ubuntu 16.04 version of the source package and submit it for build for the specified version: https://opensourcehacker.com/2013/03/20/how-to-backport-packages-on-ubuntu-linux/#Running_backportpackage_command
If the backportpackage command doesnt work (which usually means there is a dependency name change). Then I would download the ubuntu 16.04 version and modify the control and changelog to make it work and try to upload that.
Going with (3) and since gr-fosphor does not appear to have tagged
releases, would the version be after the GNU Radio version plus git
commit? E.g. 3.7.9-3.e1eb11b-myriadrf1 ?
If thats what Ubuntu 16.04 was already using for a naming convention. I have seen some other packages like that too. Its probably fine.