Based on the current translation mechanism, this behaviour is correct independently from the mode you've got for your target languages.
The mechanism works the same way for both, connected and free mode, and even the same way with an "alternative source language":
- Copy the record from the default language to the target language
- Fill in the content and give it a prefix if configured
- either based on the default language record
- or based on the alternative source language
- Fill in the uid value of the element used as a source to the l10n_source field
Only for the connected mode there is an additional information for the l18n_parent field, that determines the connection between default parent and translated child.
So to make the actual translation work, you will always need a record in the default language first, otherwise the base for the translation is missing. Even with an alternative source language, the record itself does not come from that source language, but the content does.
That's why the translate button is only visible, if there is content in the default languagea and that's why especially that alternative source language only makes sense, if you are in connected mode, which makes sure, there are no other elements in that source language, which might be missing in the process.
We could discuss a feature request though, that would treat the alternative source language as a fully fledged default language instead of using two sources to get the data from. In that case, I would expect a translate button without any defauilt language records too.