It seems to me that you will be relinquishing puppet's ability to maintain the content of the file by doing this. If that's acceptable, use the replace parameter to only have puppet maintain the initial config and allow the file to be changed outside puppet moving forward. If that's not acceptable, then the location from which the template values are derived must be updated in lock-step with the changes you make externally to puppet. This may be possible programmatically depending on your scenario, but it feels like the wrong direction to go to me.
I might approach this with a wrapper class that has awareness of resource A and resource B, and feeds them both the proper parameters to satiate their needs when cohabitating.
Alternatively, I might stub out a conf.d style config directory and provide to resource B a handle into resource A's config file through an included config file owned by resource B.
=MobileMail=Please excuse brevity or spelling errors