Puzzling problem with constraint

I was trying to implement an [example](https://hackage.haskell.org/package/tagsoup-0.14.8/docs/Text-HTML-TagSoup.html#t:ParseOptions) from the tagsoup package. (The example has typos but that's not relevant here.)

Specifically, there is a value

```haskell
parseOptions :: StringLike str => ParseOptions str
```

and I want to override some of its fields at `str = String`

```haskell
parseOptionsPreserveEntities :: ParseOptions String
parseOptionsPreserveEntities = parseOptions
{ optEntityData = \(str,b) -> [TagText $ "&" ++ str ++ [';' | b]]
, optEntityAttrib = \(str,b) -> ("&" ++ str ++ [';' | b], [])
}
```

But this doesn't work

```
app/Main.hs:10:32: error:
• Ambiguous type variable ‘str0’ arising from a use of ‘parseOptions’
prevents the constraint ‘(Text.StringLike.StringLike
str0)’ from being solved.
Probable fix: use a type annotation to specify what ‘str0’ should be.
These potential instances exist:
instance [safe] Text.StringLike.StringLike String
-- Defined in ‘Text.StringLike’
...plus four instances involving out-of-scope types
(use -fprint-potential-instances to see them all)
• In the expression: parseOptions
In the expression:
parseOptions
{optEntityData = \ (str, b) -> [TagText $ "&" ++ str ++ ...],
optEntityAttrib = \ (str, b) -> ("&" ++ str ++ [';' | b], [])}
In an equation for ‘parseOptionsPreserveEntities’:
parseOptionsPreserveEntities
= parseOptions
{optEntityData = \ (str, b) -> [...],
optEntityAttrib = \ (str, b) -> ("&" ++ str ++ ..., [])}
|
10 | parseOptionsPreserveEntities = parseOptions
| ^^^^^^^^^^^^...
```

I don't actually understand *why* it doesn't work. A workaround is to convert it into two record updates:

```haskell
parseOptionsPreserveEntities :: ParseOptions String
parseOptionsPreserveEntities = parseOptions
{ optEntityData = \(str,b) -> [TagText $ "&" ++ str ++ [';' | b]] }
{ optEntityAttrib = \(str,b) -> ("&" ++ str ++ [';' | b], []) }
```

I'm not sure whether I can suggest a candidate for a good error message because I don't actually understand what's going on. Perhaps multiple record updates desugar into something that breaks type inference. Perhaps this could be detected and a helpful suggestion to split the update into multiple single-field updates could be emitted.

(GHC 8.10.7)