Are these two problems effectively solved with segregated witness?
One is; one is not. Specifically:
(1) The anchor transation id required for the commitment input will only be known once the anchor is signed.
Segwit fixes this. If the anchor transaction contains only segwit inputs, then its transaction identify (txid) does not change when signatures are added. This allows other transactions (such as the Lightning commitment transaction) to refer to its outputs regardless of whether or not it has been signed.
(2) The anchor transaction can be malleated by either party before entering the blockchain, rendering the commitment input unusable.
Segwit does not fix this specific problem, but it does fix an important related problem. As the paper you cite says, "The last of these is particularly pernicious, as BIP62 doesn't solve it: signatories can always re-sign a transaction, hence altering its transaction ID."
The anchor transaction is created with inputs each user unilaterally controls (or shares control with a third-party to the Lightning channel currently being opened, an irrelevant detail to this discussion). Because of this, each user has the ability to create a full double spend of their part of the anchor transaction; if that double spend is what's included in the block chain, then any children of earlier versions of the transaction (such as the commitment transactions) are invalid.
The important related problem segwit does solve is useful to Lightning and required by other smart contract protocols. A payment in a payment channel (including Lightning) uses multisig to require both parties sign the payment under regular circumstances, called 2-of-2 multisig. Because signatures sign all of the non-signature data in a transaction (normal SIGHASH_ALL) but are currently included when generating the txid, either party can unilaterally malleate a transaction by changing his signature.
But with segwit, all non-signature data in a transaction is still signed but the signatures are not covered by the txid, so neither party can unilaterally change the txid without invaliding the other party's (or parties) signature or signatures. In other words, it requires both 2-of-2 to change a txid or, more generically for m-of-n, segwit requires at least m participants to change the txid.
This simplifies the design of Lightning-style Hashed TimeLock Contracts (HTLCs) and also improves the privacy of outsourcing channel enforcement, but is not required for Lightning. However, it is required for some other smart contract protocols that use sequences of transactions. For example, a Spillman-style payment channel would be secure using segwit but today it is vulnerable to malleability.
