[SalesForce] Can users edit VisualForce pages in a managed package

The way we did this in FinancialForce (as mentioned by eyescream above) was to include the VF page in the managed package, but ensure that the controller and all methods the page called by the page (same with any components you use) were marked as global. So the button defaults to using that VF page, all good.

When the customer wants to override it they clone the page (copy + paste the contents), change the 'c:' references to the package namespace, eg. 'myns:' and save. The page should work as before. Then by having a custom setting defined to override the print VF page to be used we have code behind our print button that checks if there's a value, if there is it constructs the PageReference to redirect to from that (passing in the id of the record to print, so no using Page.PDFPageName), otherwise it uses the managed package version (Page.PDFPageName in your case). So something like this in the controller:

global PageReference getPrintPage()
{
    Id invoiceId = stdController.getId();
    PageReference printPage = Page.PDFPageName;      

    String customPageUrl = MySettings__c.getInstance().CustomPrintPage__c;
    if( !String.isBlank( customPageUrl ) )
    {
        printPage = new PageReference( customPageUrl );
    }

    printPage.getParameters().put( 'id', invoiceId );

    return printPage.setRedirect( true );
}

Your code to attach the PDF to the record (or in our case mark a document as 'Printed') lives in the controller so will still be called by the overridden page since it's using the same controller behind the scenes.

Yes we've done this and been successful.

However your correct to be cautious about it though. We've had things go wrong under the hood in the past (typically with more complex dependencies than your describing here though). So long as you're not under major pressure to release Salesforce support have in our experience been able to pick through things for you and sort things out, just be sure not go messing around further if things appear odd.

Uninstalling from Packaging Org. So long as you no longer have any references to it, it will uninstall as normal, even from a packaging org. If however you've made references to it via fields lookups for example, that you cannot remove or edit out from your package, because those have been released you will not be able to break the dependency. This doesn't mean you cannot install the unmanaged version, as this will be in the your packaging org namespace. Its just that it would look a little odd to admins in your subscriber orgs to see the same classes, objects etc from the Action Plan namespace and your package namespace, other than this urglyness that may be tolerable.

Uninstalling from Subscriber Org. This again will be possible once you the subscriber org has upgraded to your new dependency free version of your main package.