Logical Records in Merge Replication

Good Day All,

We're currently running SQL Server 2008 R2 in a merge replication topology.  Publisher and distributor are on same machine.

I've done some reading on the use of Logical Records to process merge changes as a unit across related tables.  However, I've discovered three key points (from BOL):

1) Use of Logical Records has been deprecated and not recommended for use in future development work,
2) Child tables can only have one parent table, and
3) Custom conflict resolution with BLH or custom resolvers is not supported for articles forming a Logical Record.

The concept of processing merge changes across related tables as a single transactional unit is ideal based on our changing business requirements.  To describe our environment, we have several shared tables in use in our replication scheme.  One would be similar to:

CREATE TABLE [dbo].[Test]
    (
    [TestID] [varchar](50) NOT NULL,
    [DocumentTypeID] [varchar](50) NULL,
    [DocumentID] [varchar](50) NULL,
    [TestDate] [datetime] NULL,
    [Remarks] [varchar](1048) NULL,
    [UserID] [varchar](50) NULL,
    CONSTRAINT
        [PK_Test_TestID] PRIMARY KEY CLUSTERED ([TestID] ASC)
    WITH
        (
        PAD_INDEX = OFF,
        STATISTICS_NORECOMPUTE = OFF,
        IGNORE_DUP_KEY = OFF,
        ALLOW_ROW_LOCKS = ON,
        ALLOW_PAGE_LOCKS = ON
        )
    ON [PRIMARY]
    )
ON [PRIMARY]
GO

In our merge publication, [dbo].[Test] is configured as a joined table (unique key) to multiple filtered tables via the [DocumentID] column ([DocumentID] is unique across all filtered tables).  We'd much prefer to continue to keep the shared tables scheme we have in use.  However, we'd also like to pursue the logical records avenue.  If the feature is being deprecated, what are our options to achieve the same end goal?  Would there be a way to process merge changes as a unit using Business Logic Handlers?

Any assistance in this regard is greatly appreciated!

Best Regards
Brad