I had this problem too a couple of weeks ago and while mine is custom, I designated it as a date table. Unfortunately I don't remember if I designated the date table as such before or after I had created the relationships. I think it will allow you to create the relationships regardless of if you designate the table before or after you draw them.
As for why it doesn't work the way you described, I think it's because only the format was changed from datetime to date, not the actual data type. I had the same thing happen to me a few weeks ago and I solved it in a similar way in PQ because I had to preserve the time component (I just created a custom column and used the Date.From function in PQ, but I was trying to be more explicit, your way obviously worked too). If I'm reading your post right, you initially changed the format with DAX after the data loaded. This is not explicitly changing the data type, you're only changing how you're displaying it. I suspect that if you had tried actually changing the data type from datetime to date in the option above the display format option in the Modeling tab in the loaded data model, it would have worked too. I don't know if that fits your requirements though, you may need to preserve the time component too.
After figuring it out, I tried to find some explanation of why it behaves that way but I really couldn't find much. My best (somewhat) educated guess is that once you designate a date table, the relationship only truly "works" if the key column in the date table is the same data type as the column in the fact table. I suspect it lets you create the relationship because of the date component in both values but doesn't truly recognize the relationship because the time component creates some ambiguity between the tables. Your method of creating that extra column and explicitly changing it to a data type of date worked because that value is explicitly a date and can create that one-to-one relationship with respect to matching a specific date key. Obviously in practice the relationship should be one-to-many, but I think that unless the date column in the fact table can match to a specific key value, it doesn't work. If you had changed the type in the Modeling tab of the loaded model (not just the format), it would have accomplished the same thing because it actually goes back and changes the PQ script to reflect the new data type.
I think the behavior has to do with when you designate as a date table, you're only allowed to pick columns where the value is of date data type, not datetime. My guess is that this establishes the column you pick as a primary key of sorts even if it's not technically the primary key of the table if you were getting it from a database for example. For the relationships to work properly, I think the column in the fact table has to be of date data type too.
I have a feeling if you didn't explicitly mark it as a date table the relationship would work fine. In my experience the only advantage marking a date table as such gives you is if you need to do some of the more advanced time intelligence calculations past the built in YTD, SAMEPERIODLASTYEAR, etc. functions. Where I work we have a week based fiscal calendar that renders the built in time intelligence functions unusable for anything dealing with fiscal year calculations, so I am pretty much forced to designate a date table. I don't actually mind, I just have to remember to create an extra column in my fact tables that contain the date only if I need to keep a column with the original datetime value for visualization purposes.
If you don't need to use a custom calendar or do any advanced time calculations, I think you can probably get away without designating a date table. If all you need is something for a continuous axis in a visualization or use with slicers/filters, I'm pretty sure you could just create a date table that you use solely as a dimensional table, not mark it as a date table, and still be able to slice using a relationship between the date column in the date table and any datetime or date column in a fact table.
Hope this helps. I'm not claiming it's the official explanation or anything, it's just my best guess. If anyone else knows exactly why this happens, I'd be interested in hearing it too.
Andrew
