For people having the same problem, this har been registered as a bug: http://world.episerver.com/Support/Bug-list-beta/bug/116674/

It works fine in EPiServer 7.5, but with the latest update it does not work 

I am having the same problem as this when trying to validate a block type.  I have tried testing for the item ID being greater than zero.  At creation its ID will be zero. So my Validate() method looks like this:

IEnumerable<ValidationError> IValidate<SoundCloudBlock>.Validate(SoundCloudBlock instance)
{
    var contentItem = instance as IContent;
 
     if (contentItem.ContentLink.ID > 0)// Test if it has been created yet
    {
        /* ..... */
    }
}

Does this work here?

Unfortunately, this doesn't work across the board.  When creating a new block in a content area by clicking on "create a new block" at the bottom of the content area in on-page edit mode, the block gets created and published in one go, so if you test for the ContentLink.ID being greater than zero before validating, you will miss this scenario and an editor can create a new block, avoiding your custom IValidate validator and publish the block without realising it.

I can not fully understand why the behavior needs to be different when creating/adding Block from ContentArea or if not. I have reported this as a bug to EpiServer (it was a while ago and nothing has happened yet). I guess the reason for this is that, with the current solution, has the block to be created/published first to be able to connect/add it to the content area. There must be solution available to add uncommited/unsaved blocks to ContentAreas.

In my case is the problem that I have designed nice BlockEditor views. They are not used when adding Block from ContentArea (works fine when creating block from block gadget, +-sign or "New block").

I hope this gets fixed soon since many user prefer to create the block using "Create new block" in the ContentArea. (And I don´t want to disable it yet since this is the most logical workflow)

I agree.  I can't see the reason for changing the creation interface depending on where you start the creation journey.  Also, publishing a block on creation without viewing it first by using the ContentArea method seems risky and illogical to me.

Yes, It's a risky solution and my guess is that this also might be the reason that we sometimes get blocks thats has "no parents". Might be due to something went wrong after creating the block and before adding it to the ContentArea in the "Create block in ContentArea"-workflow. These "parentless" blocks show them selves when when creating a new page or block. Disappears when other blocks is added to the page. (By the same. It´s the same risk/problem for images since they auto publish by default)

Well... offl topic now. Sorry about that. Just want to confirm that you a solutions you come up with will probably not work when it comes to the "Create block in ContentArea"-workflow.... and as I already said I hope this will be fixed soon.