I always work better with concrete names, so I will make up a few branches. Let's say you are building a blog web application. What you call "featurea" I will call "blog_posts". What you call "featureb" I will call "comments".
I'm going to assume the git commands that were executed were roughly:
git checkout dev
git merge blog_posts
git checkout blog_posts
git checkout -b comments
As of merging blog_posts into dev you could potentially create a merge commit in dev that does not exist in blog_posts if you have not merged the latest from dev into blog_posts. Upon creating the comments branch it will point to the tip of blog_posts, which would not contain the merge commit. So yes, it does matter which branch you create the new branch from, however...
Don't worry too much about this. If you created the comments branch from blog_posts and meant to create it from dev, merging dev into the comments branch results in a fast forward merge if no commits were added to the comments branch.
If you added commits to the comments branch you can just merge dev into comments and move on with your life. If the comments branch has not been pushed yet, rebasing this branch on dev will rewrite the history of the comments branch to look as though it had been created from dev in the first place.
Even though it does matter which branch you create a new branch from, git allows you make corrections to the history of the branch prior to pushing it. Don't sweat this decision too much given the situation you described. The two branches don't seem like they have diverged that much, so the risk of totally screwing up the code base is minimal.