You only always notify valid blocks of your "officially deemed" branch of the chain. This means that if if you come to know of valid side branches you never propagate those to the other nodes.
In your example where you know of a more recent "unlinked" piece of a chain with forks you remember it but ignore it, keeping mining on the last valid block on the longest chain you know of (that cannot be in the "unlinked" chain). If at a subsequent time you receive the missing block(s) to link the more recent piece of the chain (and everything is valid) AND this new piece of the chain is LONGER than the old longest branch then:
1) you start mining on the latest valid block (on the new branch under the previous assumption its longest);
2) you communicate the new longest branch to the other nodes as usual (this means the linking block(s) and the entire branch until the block you're currently mining on).
Always remember the rule that a COMPLIANT miner notifies only new blocks on the branch it think is the official one (which is the same that it's mining on). The previous explained behavior is just an application of such rule.
IMPORTANT NOTE:
A lot of students have been asking questions about this and deep forks in the chain, especially regarding the amount of memory required from every node to remember all the forked or "unlinked" branches. TO SOLVE THE PROJECT MORE EASILY YOU CAN EMULATE A REAL BITCOIN FEATURE CALLED "CHECKPOINTS". THIS SIMPLY MEANS THAT YOU ASSUME THAT A BLOCK IN YOUR CURRENT CHAIN AT DEPTH MORE THAN k THAN THE LATEST OFFICIAL BLOCK IS NOT MODIFICABLE. IN CASE OF FORKS THE DEPTH EVALUATION SHOULD TAKE INTO ACCOUNT NOT SIMPLY THE BLOCK HEIGHT BUT ALSO THE DIFFERENCE BTEWEN THE LATEST BLOCK AND ALL THE OTHER BRANCHES. For example if k==3 and the blockchain looks like this:
b90---b91---b92---b93---b94---b95
The last block is b95, but the last "checkpoint" is b90 and NOT b95 (that would be the block at distance 3 from the last block). This is because the b94'' has only a 1 height difference from b95 branch that is smaller than 3. To better understand if you consider the case:
b90---b91---b92---b93---b94---b95--b96
Then b93 is the correct checkpoint.
THE VALUE OF k SHOULD BE A GOOD COMPROMISE BETWEEN USAGE AND MEMORY CONSUMPTION, BUT MOSTT IMPORTANTLY SHOULD GUARANTEE A REASONABLY MINIMAL IMPACT ON FORKS. DO CONSIDER THAT THIS SOLUTION MAY CAUSE THE CHAIN TO DIVERGE BETWEEN DIFFERENT NODES, LEADING TO NETWORK SEGMENTATION. THIS SHOULD BE AVOIDED AS MUCH AS POSSIBLE BY CHOOSING AN HIGH ENOUGH k, AND RERUNNING THE EXPERIMENTS WHEN IT RANDOMLY HAPPENS.
IMPORTANT IS TO NOTE THAT SELFHIS (OR OTHER KINDS OF MALEVOLENT) MINERS SHOULD TAKE IT INTO ACCOUNT RELEASING PRIVATE CHAINS IF THEY GET CLOSE IN LENGTH TO THE k VALUE, TO AVOID USELESS FORKS. FINALLY WE NOTE THAT THIS TRICK COULD HELP IN THE "SELFISH MINERS ONLY" SCENARIO TO TRIGGER EVENTUAL BLOCKS PUBLICATION.