Alarm bells ring in my head when I see attributes of the same type repeated on one entity, it always comes back to bite when another relationship needs described and the schema has become difficult to migrate. That's not to say its always a cast iron rule, just something I'm always aware of. What I'd do in your Conference -> Speaker example is change it so you have a Conference entity, a Speaker entity and ConferenceSpeaker entity that maps the relationship between a Speaker and a Conference. Once you do this it becomes clearer where the attribute "speaker order" should go and allows you to create Conferences with zero to
n Speakers without having to change your data model. If you are worried about not having two Speaker 1s at Conference A you can use unique constraints to prevent this.
Likewise with your Project example, how do you use the entity as your defined it if two Users asume co-responsibility for a single Project? This could be remodelled to have an entity called Project, one called User and another called ProjectUserRole, which again maps and describes the relationship between a Project and User(s).
You don't have to go this route - I only bring it up as something to consider. If you want to keep your data model as is you need to be aware that the "name" of the join column refers to the attribute of the mapped entity, not the key on the associated entity. So you would need to join on three differernt attributes of Conference (say, speaker_1_id, speaker_2_id and speaker_3_id) rather than trying to define one attribute that describes three associations - which is of course impossible.