Hi there!
There are a few approaches to managing services across environments on Render, so first let me see if I can address some of your questions.
There is nothing environment specific in our blueprint etc. So our services are created with the same name. This can cause confusion when reviewing services and logs. I’d rather have services created by the staging blueprint instance have a “-staging” appended etc. Is the best way to achieve this to manually rename the services after they have been created by the blueprint’s sync?
Since services of the same type can’t have the same name, when you create a new Blueprint instance using the same render.yaml, those services will be prepended with a short string to make them unique.
Generally the approach you’ve defined should work just fine, but as you noted, it’s not perfect. I’ll give you a couple other options to consider!
Alternative 1: One Blueprint instance, multiple services for each environment
In this solution, you’d only have one Blueprint instance, but you’d define your staging- and production- services all in the same render.yaml. This would allow you to override things like env vars, autodeploy, etc wherever necessary, and you can adopt whatever naming convention works for you. This does require listing each service twice (with overrides) in your Blueprint spec, but it might be a better option since it 1) fixes the environment-specific naming issue and 2) allows you to override service configuration for staging.
Alternative 2: Use Teams to differentiate staging and production services
In this solution, you’d have a team for staging and one for production. Services are allowed to have the same name when they’re separated by teams. Then in order to override environment variables, you’d have your services use env vars from a particular environment group, which would be named the same in both teams, but have different values for the variables.
Hope that helps! As to this…
I’ve read a few hints that there’s work being done in this area. I suspect the Heroku Pipeline features is often asked for. Any updates?
Yes! I am one of the engineers working on this feature, and what we’re developing will allow users to group related services into projects that consist of multiple environments. I can’t get too into the nitty-gritty details since it’s still in development, but I can absolutely confirm that this is something we’re actively working on. 
Is the approach we’re taking here compatible with what is planned, or are there tweaks we can make now that will make migration to a future pipeline-like solution smooth?
A primary goal for introducing projects and environments is to make it easy for existing users to transfer their services into a project. After all, lots of folks have been asking for this, including myself!! 
From what you’ve described, it doesn’t sound like you’d have any trouble migrating to projects.
Hope this helps!
Annie